Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-02 Thread Walter H. 

On 01.08.2017 23:15, Ted Lemon wrote:
I addressed that question in a previous reply.   Your home network 
does not have the equivalent security to letsencrypt.org 
's certificate signing infrastructure (I hope!!).
that is not the question, the question is: is it possible to use some 
self signed certificates without trust anchor installed, in the near future?

by the way how would you distinguish between LAN and WAN in an IPv6 world?
in an IPv4 world it is done by RFC1918 addresses ...
  Installing a trust anchor means that trust anchor has signing 
authority for any name---there's no way to install one that doesn't.

there is a way, look at this one:

-BEGIN CERTIFICATE-
MIIJWTCCCEGgAwIBAgIQeRdKqRQXNv4Vp8qfLP9FiDANBgkqhkiG9w0BAQUFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTEzMDIwMTAwMDAwMFoXDTIwMDUzMDEwNDgzOFow
UjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMScwJQYD
VQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kgQ0EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDCuISVQi3csKqYk5uz7IOhY8MXkiqBaTqagiht
iM997G1mJhTojcR+8DCg3E8OQ3ZajByhxRkwlsR4Srl5sGSwWfF/XaAHGUhWIhjB
kDO7toW+EMzI8pAjcLwIbRlIL0AFnUTe6Z0DcIS5406Y/9MKE2oKXbf4EbVBv88m
SkA74Z+lZJWFNxXncx/9wq8UdyMY2vHN1Kir1/JbtrqB9wYRBjQtWSbAVZR8nTBP
yRp4uvQTS2jOQh+jTUo1Y3O/o1xg/zRA4FEOUCla704OYRUkc8NuXHiPNNDcktr7
gO8E06NVQ6n6aBGaOJbSst2vHA7Eiog7A2PB4wKn+GDFf+FNAgMBAAGjggYMMIIG
CDAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUVjpv
F6skDOW3MWSwEe3b6iO+XrwwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB
Af8CAQEwXgYDVR0lBFcwVQYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYI
KwYBBQUHAwQGCCsGAQUFBwMIBgorBgEEAYI3CgMEBgorBgEEAYI3CgMMBgkrBgEE
AYI3FQUwFwYDVR0gBBAwDjAMBgoqhkiG+E0BBQFpMEkGA1UdHwRCMEAwPqA8oDqG
OGh0dHA6Ly9jcmwudHJ1c3QtcHJvdmlkZXIuY29tL0FkZFRydXN0RXh0ZXJuYWxD
QVJvb3QuY3JsMIHCBggrBgEFBQcBAQSBtTCBsjBEBggrBgEFBQcwAoY4aHR0cDov
L2NydC50cnVzdC1wcm92aWRlci5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5w
N2MwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jcnQudHJ1c3QtcHJvdmlkZXIuY29tL0Fk
ZFRydXN0VVROU0dDQ0EuY3J0MCoGCCsGAQUFBzABhh5odHRwOi8vb2NzcC50cnVz
dC1wcm92aWRlci5jb20wggQXBgNVHR4EggQOMIIECqCCA9QwC4EJaW50ZWwuY29t
MAuCCWFwcHVwLmNvbTAOggxjbG91ZG5wby5vcmcwE4IRZWRhY2FkdG9vbGtpdC5v
cmcwC4IJZnRsMTAuY29tMAuCCWloY21zLm5ldDAOggxpbmMtbmVzdC5uZXQwFoIU
aW5kaWFlZHVzZXJ2aWNlcy5jb20wDYILaW50ZWwuY28uanAwDYILaW50ZWwuY28u
a3IwDYILaW50ZWwuY28udWswC4IJaW50ZWwuY29tMAqCCGludGVsLmZyMAuCCWlu
dGVsLm5ldDATghFpbnRlbGFsbGlhbmNlLmNvbTAUghJpbnRlbGFwYWNzdG9yZS5j
b20wFoIUaW50ZWxhc3NldGZpbmRlci5jb20wGYIXaW50ZWxiZXR0ZXJ0b2dldGhl
ci5jb20wFIISaW50ZWxjaGFsbGVuZ2UuY29tMBOCEWludGVsY2xvdWRzc28uY29t
MB6CHGludGVsY29uc3VtZXJlbGVjdHJvbmljcy5jb20wEoIQaW50ZWxjb3JlMjAx
MC5ydTAWghRpbnRlbGZlbGxvd3NoaXBzLmNvbTAWghRpbnRlbGh5YnJpZGNsb3Vk
LmNvbTAUghJpbnRlbHBvcnRmb2xpby5jb20wDoIMaW50ZWwtcmEuY29tMBSCEmlu
dGVsLXJlc2VhcmNoLm5ldDAUghJpbnRlbHJtYXN1cnZleS5jb20wGIIWaW50ZWxz
bWFsbGJ1c2luZXNzLmNvbTARgg9teWludGVsZWRnZS5jb20wEYIPbXktbGFwdG9w
LmNvLnVrMBKCEG9yaWdpbi1hcHB1cC5jb20wHoIcb3JpZ2luLWludGVncmF0aW9u
LWFwcHVwLmNvbTAIggZwYy5jb20wFIIScGN0aGVmdGRlZmVuY2UuY29tMBSCEnBj
dGhlZnRkZWZlbnNlLmNvbTAOggxwdmF0cmlhbC5uZXQwGYIXcmVkZWZpbmV5b3Vy
bmV0d29yay5jb20wD4INcmV0YWlsLWlhLmNvbTAUghJzZXJ2ZXItaW5zaWdodC5j
b20wE4IRdGhlaW50ZWxzdG9yZS5jb20wHYIbdGhyZWFkaW5nYnVpbGRpbmdibG9j
a3Mub3JnMBuCGXRodW5kZXJib2x0dGVjaG5vbG9neS5uZXQwIIIedWx0cmFib29r
LXNvZnR3YXJlLWNvbnRlc3QuY29tMFCkTjBMMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExFDASBgNVBAcTC1NhbnRhIENsYXJhMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbqEwMAqHCAAAMCKHIAAA
MA0GCSqGSIb3DQEBBQUAA4IBAQBYb7/NQwdCE/y40K2BIfKKb++H
vCaKfAC9aAwrGWQsEWezqdl5Cqw5XWUAFjtTRm6iprVnmdvov6IlrgSVEQk6L96s
tz24vAF0MIBHSFRMoPtrqLiihLf0NOV7ztxSePQxbUJRroe/lKy+lhb7VeV5gmT9
rFA45NzLgSznd2+dmyNcfQQD9AeeftRX4maUTeu1XFxinowtg+ZGFOKhE4D92uCG
JxGSK72HF0/LGRhLXozmDdmPfSN2b6T/oLo942031iY46BqcI5LIVh8aGo4A1jOm
a5X6gh50Cw+kht8jM3yeNhSzXOKj7Uigjijx10z2wJu09Tyj5ahjoiwIpdX+
-END CERTIFICATE-

I mean, honestly, if it were possible to get a CA to just issue 
certificates for "www.home.arpa" on request with no validation, I 
think that would be a better answer both from a security perspective 
and a usability perspective, but it's not a /good/ answer, and I don't 
think it's possible anyway.



exakt this was the intention of my inital thoughts


smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Walter H. 

On 01.08.2017 21:21, Ted Lemon wrote:
On Aug 1, 2017, at 2:53 PM, Walter H. > wrote:
is there a problem, to have the organization that has the delegation 
of ".home.arpa." also provide such SSL certificates

signed by an intermediate that got signed by any CA?


This is not how PKI works.
wrong exact this is it; a PKI has at least a root CA and end entity 
certificates, and of course I never mentioned this, the browser does 
validate checks - either CRL or OCSP, and all this is meant by running a 
own PKI 

and this is not everyones thing to have this configured ...


smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Ted Lemon 
I addressed that question in a previous reply.   Your home network does not
have the equivalent security to letsencrypt.org's certificate signing
infrastructure (I hope!!).   Installing a trust anchor means that trust
anchor has signing authority for any name—there's no way to install one
that doesn't.   So now you've opened all those hosts to attack.   Plus, you
have to install the trust anchor on a bunch of hosts.   Aside from the bit
about our charter saying the host needn't be modified, that's an IT problem
that would challenge a lot of fairly computer-literate people, and if apps
are trusted to do it, that's a major security vulnerability waiting to be
exploited.   If you mean install a cert for every device that presents a
web browser, well, eep.   Aside from the "trusted app" issue and the
"that's hard for end-users" issue, I guess that isn't quite as scary, but
I'd really like an operational model that doesn't require it.

I mean, honestly, if it were possible to get a CA to just issue
certificates for "www.home.arpa" on request with no validation, I think
that would be a better answer both from a security perspective and a
usability perspective, but it's not a *good* answer, and I don't think it's
possible anyway.

On Tue, Aug 1, 2017 at 5:06 PM, Michael Richardson 
wrote:

>
> Ted Lemon  wrote:
> barbara> The CABF is about "publicly trusted certificates". There is
> no need or
>
> ...
> > (2) the issue with browser warnings isn't that they are annoying.
> It's that
> > if we train users to click through them when managing the homenet,
> we are
> > also training them to click through them at other times. This
> creates an
> > attack surface in the user that we'd rather not create.
>
> I was trying to understand how CABF was relevant.
>
> I guess the point was how to get a new trust anchor added *globally* that
> would somehow be able to issue certificates that were relevant/bound to
> home.arpa names?
>
> I don't think that this is an immediate concern; if we had some useful
> experiment that we could do we could do it with a sub-CA or with a private
> anchor.
>
> I think that Windows, OSX, and Android have system-wide ways to install new
> trust anchors that browser will generally trust.  libnss on many Linux
> distros provides something similiar.  I assume iOS does too.  As such, it
> should be possible for an application/app on a home desktop to exist that
> would interact with all the devices involved (providing certificates from a
> private trust anchor), and to install the private trust anchor.
> How one spreads that trust anchor to the rest of the family, relatives,
> etc. is an issue.
>
> but, none of this is really relevant to delegation of home.arpa, I think.
>
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Michael Richardson 

Ted Lemon  wrote:
barbara> The CABF is about "publicly trusted certificates". There is no 
need or

...
> (2) the issue with browser warnings isn't that they are annoying. It's 
that
> if we train users to click through them when managing the homenet, we are
> also training them to click through them at other times. This creates an
> attack surface in the user that we'd rather not create.

I was trying to understand how CABF was relevant.

I guess the point was how to get a new trust anchor added *globally* that
would somehow be able to issue certificates that were relevant/bound to
home.arpa names?

I don't think that this is an immediate concern; if we had some useful
experiment that we could do we could do it with a sub-CA or with a private
anchor.

I think that Windows, OSX, and Android have system-wide ways to install new
trust anchors that browser will generally trust.  libnss on many Linux
distros provides something similiar.  I assume iOS does too.  As such, it
should be possible for an application/app on a home desktop to exist that
would interact with all the devices involved (providing certificates from a
private trust anchor), and to install the private trust anchor.
How one spreads that trust anchor to the rest of the family, relatives,
etc. is an issue.

but, none of this is really relevant to delegation of home.arpa, I think.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Ted Lemon 
On Aug 1, 2017, at 2:53 PM, Walter H.  wrote:
> is there a problem, to have the organization that has the delegation of 
> ".home.arpa." also provide such SSL certificates 
> signed by an intermediate that got signed by any CA?

This is not how PKI works.   For a browser to trust a signing authority, the 
signing authority has to be vetted as trustworthy.   Honestly, PKI is a bit of 
a dumpster fire, but the point is that adding this requirement, even if we 
could, would not improve the situation.   Please understand that the goal of 
network security, including PKI, is not to make warnings go away: it is to 
protect users from attacks on the  security of their information and devices.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Walter H. 

On 01.08.2017 20:04, Ted Lemon wrote:
On Aug 1, 2017, at 2:02 PM, Walter H. > wrote:

what is the real problem having stricht rules in this Draft/RFC to get an
SSL certificate that can be used  inside such an environment;
so that no own PKI is neccessary?


The problem is that it's not up to us to set these rules—it's up to 
CABF, and they have ruled on this, and (IMO) not capriciously.


is there a problem, to have the organization that has the delegation of 
".home.arpa." also provide such SSL certificates

signed by an intermediate that got signed by any CA?

and these should be a section in this Draft/RFC ...

so that there is neither need of errors/warning neither red nor cowblue 
or other color; and also no need of having an own PKI

when not wanted to or or not having the knowledge about at all;

it would be quite strange to think that anybody that use a browser for 
electronic banking has the knowledge about SSL ...
by the way knowledge about SSL is more common than knowledge about 
DNSSEC ...


in good old german we would say: "wo ein Wille da ein Weg" or in strange 
English: "a way is open when its wanted to be open"





smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Ted Lemon 
On Aug 1, 2017, at 2:37 PM, Juliusz Chroboczek  wrote:
> Think of it as a knob with a wasps' nest behind it.

I know how to build it, so no, I don't think of it that way.   I can think much 
worse wasp's nests.   One example would be a network with no trust model that 
encourages end-users to engage in very risky practices in order simply to use 
it.   I don't think we can fully mitigate that problem, but I think it's worth 
thinking about what we _can_ do to mitigate it.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Juliusz Chroboczek 
> The bottom line is that a global delegation+ACME PKI is a knob I can turn.

Think of it as a knob with a wasps' nest behind it.

> Fixing browsers is a knob I can't turn, and the browser vendors have spoken
> pretty unequivocally on this topic. If you want to tilt at that windmill, I
> will gladly lend my voice, but I am not hopeful.

Thanks for the offer, but no.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Ted Lemon 
On Aug 1, 2017, at 2:02 PM, Walter H.  wrote:
> what is the real problem having stricht rules in this Draft/RFC to get an
> SSL certificate that can be used  inside such an environment;
> so that no own PKI is neccessary?

The problem is that it's not up to us to set these rules—it's up to CABF, and 
they have ruled on this, and (IMO) not capriciously.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Ted Lemon 
On Aug 1, 2017, at 1:33 PM, Juliusz Chroboczek  wrote:
> Agreed.  The problem, of course, is not Homenet-specific -- I've got
> exactly the same problem with my printer, or with Babelweb.  The problem,
> in short, is that HTTP doesn't allow either BTN or TOFU security -- it's
> either creartext of CA-based (or big red warning).

Yup.

> I think that Barbara expressed very clearly why the CA model is simply not
> adapted to the Homenet.  I don't think we should be complicating the
> Homenet protocol stack in order to work around the limitations of the
> browser stack.

Best is the enemy of good enough.   Also, you routinely overestimate how 
complicated this stuff is.   I appreciate that you value simplicity, but the 
rule I prefer to follow is: "make it as simple as possible, and no simpler."

The bottom line is that a global delegation+ACME PKI is a knob I can turn.   
Fixing browsers is a knob I can't turn, and the browser vendors have spoken 
pretty unequivocally on this topic.   If you want to tilt at that windmill, I 
will gladly lend my voice, but I am not hopeful.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Walter H. 

On 01.08.2017 19:33, Juliusz Chroboczek wrote:

I think that Barbara expressed very clearly why the CA model is simply not
adapted to the Homenet.  I don't think we should be complicating the
Homenet protocol stack in order to work around the limitations of the
browser stack.

I'm not thinking about the homenet protocol I think of the fact that the
'.home.arpa' is the general purpose domain which can be used in home 
networks
just for simple DNS, there is nothing said about the homenet protocol at 
all;


what is the real problem having stricht rules in this Draft/RFC to get an
SSL certificate that can be used  inside such an environment;
so that no own PKI is neccessary?

by the way, when you look at the x509 certificate chain, that is used by 
intel.com
you find an intermediate, that this can only be used to sign requets for 
domains that Intel own ...

why not just having such a intermediate for '.home.arpa.' domains?
this intermediate can even be public including its private key ...

in a short time there will be no way to go over the warnings in browsers,
these will be errors, where any connection will be blocked.



smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread STARK, BARBARA H 
> In order for a PKI solution to work, it has to be possible for any given cert 
> to apply to a unique name, the ownership of which can be defended somehow.   
> The CABF has spoken unequivocally on this topic:
> https://www.digicert.com/internal-names.htm
> The point of having PKI in the homenet is so that we have secure connections 
> between browsers and servers, and so that users aren't trained to click 
> through certificate warnings just to get things working.   Any solution to 
> this problem has to meet those two requirements.   And to achieve the second 
> requirement, the CABF is going to want it to be the case that the cert 
> identifies a specific endpoint for communication.
> When I say "I don't know how to do that," this is what I'm talking about.   
> Actually, I do know how to do it: get a public delegation.

The CABF is about "publicly trusted certificates". There is no need or 
applicability of "publicly trusted certificates" in the context of a home 
network. No certificate authority in the world is capable of certifying that a 
device inside a specific home network actually belongs there. The only entity 
capable of identifying devices that belong in the home network is the home 
(network) owner. This isn't about public trust. It's about private trust.

In reading Stephen's email about what he did wrt certificates, what stood out 
to me were:
 (1) The primary goal was to stop the annoying browser warnings. [note that 
neither HNCP nor Babel would be expected to check against CAs stored in 
browsers, so they would not be subjected to this annoyance; but the annoyance 
is something to prevent when considering the broader "naming architecture"]
 (2) Stephen (the home network owner) was the assigner of trust. He was the 
root certificate authority.

We had discussed (back in Chicago) that a first step should be to figure out 
first what our goals were wrt "security". From the perspective of the end user, 
here is my starter list of considerations:
1. End users would like to know that device software / firmware has no Trojans 
and is "good". This is not a good fit for X.509 certificates or PKI. This would 
be something for some logo-based certification program (like a UL, Good 
Housekeeping, IPv6 Ready, etc. stamp). I think this is outside the (current) 
scope of homenet and there are other orgs working on this sort of thing. In any 
case, it has nothing to do with encryption and X.509 certificates.
2. End users are the absolute (root) authority as to what does and doesn't 
belong on the home network. No one else. Even in the case of "unmanaged" home 
networks. Verisign and others are incapable of telling me whether or not a 
device belongs on my home network.
3. End users want it to be very easy to add devices/services to the home 
network. 
4. End users want it to be very easy to remove devices/services.
5. End users want to know when devices on the home network are misbehaving, and 
they want to easily identify such devices.
6. End users don't want annoying "untrusted" warnings for devices and services 
inside the home network that they have decided to add to it.

Does this seem like a reasonable list? Are there items y'all disagree with? 
Others to add?
Thanks,
Barbara



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Ted Lemon 
On Aug 1, 2017, at 5:52 AM, Toke Høiland-Jørgensen  wrote:
> If you're going through all this trouble of having a central API that
> will hand out certificates, wouldn't it be possible to make that same
> authority hand out pseudo-random unique subdomains (of some suitable
> domain; not necessarily .home.arpa)? Then you are only an NS record from
> solving the globally visible naming problem... :)

That's what section 4 of the old homenet naming architecture document described.

https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-00#section-4
 



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Ted Lemon 
On Aug 1, 2017, at 2:01 AM, Walter H.  wrote:
> there SHOULD NOT be the ACME authentication or any neccessarity of any
> other authentication, as these domain names need not be unique ...

In order for a PKI solution to work, it has to be possible for any given cert 
to apply to a unique name, the ownership of which can be defended somehow.   
The CABF has spoken unequivocally on this topic:

https://www.digicert.com/internal-names.htm 


The point of having PKI in the homenet is so that we have secure connections 
between browsers and servers, and so that users aren't trained to click through 
certificate warnings just to get things working.   Any solution to this problem 
has to meet those two requirements.   And to achieve the second requirement, 
the CABF is going to want it to be the case that the cert identifies a specific 
endpoint for communication.

When I say "I don't know how to do that," this is what I'm talking about.   
Actually, I do know how to do it: get a public delegation.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Toke Høiland-Jørgensen 
>> you couldn't use the fact that you can publish in a name in it
>> to do the ACME authentication.
>
> there SHOULD NOT be the ACME authentication or any neccessarity of any
> other authentication, as these domain names need not be unique ...
>
> in case you use 'teddynet.home.arpa.' and I use this domain name, too;
> we wouldn't have the same x509 SSL certificate, because each of us uses
> its own private key ...
>
> why not just define the org. that hosts the ARPA TLD (IANA?), as the CA
> for these domains and the root certificate as built in token to the common
> browsers and/or operating systems?
> there it should only be neccessary to upload the certificate request,
> gicwn the '.home.arpa.' domain name, and an email address where the
> certificate is sent to;
> the certificate will be a wild card certificate for this .home.arpa.
> domain ..
>
> I would want this to be added as additional section to this Draft/RFC;

If you're going through all this trouble of having a central API that
will hand out certificates, wouldn't it be possible to make that same
authority hand out pseudo-random unique subdomains (of some suitable
domain; not necessarily .home.arpa)? Then you are only an NS record from
solving the globally visible naming problem... :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-08-01 Thread Walter H. 
On Mon, July 31, 2017 20:33, Ted Lemon wrote:
> On Jul 31, 2017, at 2:21 PM, Walter H.  wrote:
>> Just a thought of mine, would it be possible to add a section, to make
>> it possible
>> to get official SSL certificates for these 'home.arpa.' domains (for
>> free),
>> so there would not be the need of running a own PKI?
>
> I don't see how that could work.

that is why my thoughts to add a section to this Draft/RFC how this will work

>  I agree that it's a problem in need of
> a solution, but since home.arpa wouldn't be externally visible,

of course, the sense of a private LAN domain name ...

> you couldn't use the fact that you can publish in a name in it
> to do the ACME authentication.

there SHOULD NOT be the ACME authentication or any neccessarity of any
other authentication, as these domain names need not be unique ...

in case you use 'teddynet.home.arpa.' and I use this domain name, too;
we wouldn't have the same x509 SSL certificate, because each of us uses
its own private key ...

why not just define the org. that hosts the ARPA TLD (IANA?), as the CA
for these domains and the root certificate as built in token to the common
browsers and/or operating systems?
there it should only be neccessary to upload the certificate request,
gicwn the '.home.arpa.' domain name, and an email address where the
certificate is sent to;
the certificate will be a wild card certificate for this .home.arpa.
domain ..

I would want this to be added as additional section to this Draft/RFC;

> I was hoping to get IP-based certs, but it turns out that letsencrypt
> (probably wisely) doesn't offer them.

IP-based is a bad idea as there is no user agent (browser) that handles
IPv6 correct in such case ...

Thanks,
Walter

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-07-31 Thread Ted Lemon 
Thanks, Mark.   That was sufficient detail. :)

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-07-31 Thread Mark Andrews 

In message <916eeeb9-3709-492b-8e19-5c832b11a...@fugue.com>, Ted Lemon writes:
> On Jul 31, 2017, at 1:02 AM, Mark Andrews  wrote:
> > The delegatation is INSECURE and SIGNED not UNSIGNED.  The wording
> > here is *important*.
>
> Can you explain what the distinction is, and what the problem is that you
> see in point five?  The reason I ask is that we explicitly changed the
> wording from "insecure" to "not signed" because someone else said that it
> wasn't clear what "insecure" meant.   It seems to me that the current
> language is explicit and unambigious; I think this is better than being
> "correct."   So what is the bad outcome that might occur as a result of
> using the term "not signed" rather than "insecure"?

The delegation has *signed* NEC/NSEC3 records that prove that there
is no DS record at the delegation *and* that the delegation *exists*
unless OPTOUT is also set in the covering NSEC3 record.  The presence
of the NS bits without a SOA and DS bits in the validated NSEC/NSEC3
record proved that the child zone is insecurely delegated.  Note
this does not work if the delegation is unsigned.

All delegations from a signed zone are signed.  These is no such
thing as a unsigned delegation.  There are only secure (with signed
DS) and insecure (without DSi but with signed NSEC/NSEC3).

This is different to a unsigned delegation in a unsigned zone where
there is no proof of anything.

RFC 4033

   Insecure: The validating resolver has a trust anchor, a chain of
  trust, and, at some delegation point, signed proof of the
  non-existence of a DS record.  This indicates that subsequent
  branches in the tree are provably insecure.  A validating resolver
  may have a local policy to mark parts of the domain space as
  insecure.

RFC 4035

   Insecure: An RRset for which the resolver knows that it has no chain
  of signed DNSKEY and DS RRs from any trusted starting point to the
  RRset.  This can occur when the target RRset lies in an unsigned
  zone or in a descendent of an unsigned zone.  In this case, the
  RRset may or may not be signed, but the resolver will not be able
  to verify the signature.

Then add to that "insecure delegation" is the existing term for this
type of delegation.

RFC 6063

   As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
   namespaces, the zones listed above will need to be delegated as
   insecure delegations, or be within insecure zones.  This will allow
   DNSSEC validation to succeed for queries in these spaces despite not
   being answered from the delegated servers.

RFC 7719:

   Insecure delegation:  a name containing a delegation (NS RRSet), but
  lacking a DS RRSet, signifying a delegation to an unsigned child
  zone.


   Opt-out:  "The Opt-Out Flag indicates whether this NSEC3 RR may cover
  unsigned delegations."  (Quoted from [RFC5155], Section 3.1.2.1.)
  Opt-out tackles the high costs of securing a delegation to an
  insecure zone.  When using Opt-Out, names that are an insecure
  delegation (and empty non-terminals that are only derived from
  insecure delegations) don't require an NSEC3 record or its
  corresponding RRSIG records.  Opt-Out NSEC3 records are not able
  to prove or deny the existence of the insecure delegations.
  (Adapted from [RFC7129], Section 5.1)

As for point 5 the delegation for "home.arpa." will exist once IANA
adds it to the ARPA zone.  The content of the delegation won't match
but it will exist.  Note any server that performs such tests is
already broken as STD 13 requires that the child zone be setup
before the delegation is made.  I know there are DNS hosters that
require the delegation exists and list the server but they are
actually wrong to do this.  DNS delegations are make before break.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-07-31 Thread Ted Lemon 
On Jul 31, 2017, at 2:21 PM, Walter H.  wrote:
> Just a thought of mine, would it be possible to add a section, to make it 
> possible
> to get official SSL certificates for these 'home.arpa.' domains (for free),
> so there would not be the need of running a own PKI?

I don't see how that could work.   I agree that it's a problem in need of a 
solution, but since home.arpa wouldn't be externally visible, you couldn't use 
the fact that you can publish in a name in it to do the ACME authentication.

I was hoping to get IP-based certs, but it turns out that letsencrypt (probably 
wisely) doesn't offer them.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-07-31 Thread Walter H. 

On 28.07.2017 22:11, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Home Networking WG of the IETF.

 Title   : Special Use Domain 'home.arpa.'
 Authors : Pierre Pfister
   Ted Lemon
Filename: draft-ietf-homenet-dot-10.txt
Pages   : 9
Date: 2017-07-28

Abstract:
This document specifies the behavior that is expected from the Domain
Name System with regard to DNS queries for names ending with
'.home.arpa.', and designates this domain as a special-use domain
name. 'home.arpa.' is designated for non-unique use in residential
home networks.  Home Networking Control Protocol (HNCP) is updated to
use the 'home.arpa.' domain instead of '.home'.
Just a thought of mine, would it be possible to add a section, to make 
it possible

to get official SSL certificates for these 'home.arpa.' domains (for free),
so there would not be the need of running a own PKI?

Greetings,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-07-31 Thread Ted Lemon 
On Jul 31, 2017, at 11:42 AM, Warren Kumari  wrote:
> It really is an insecure delegation, not an unsigned delegation --
> calling it unsigned would be confusing to many people. The person I
> was discussing it with wasn't aware of the term "insecure delegation"
> and assumed that it meant an "unsigned delegation", which is, um,
> difficult to achieve in a non-NSEC3 OO zone...

Ah, I wrote that text not imagining that .arpa was signed using good 
old-fashioned NSEC, which was silly of me.   That said, I would rather not rely 
on interpretations of terminology the meaning of which isn't agreed upon.   I 
think it would be better to simply specify that there will be no DS record.   
Does that make sense, or is there some reason why we have to say "unsigned?"

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-07-31 Thread Warren Kumari 
On Mon, Jul 31, 2017 at 5:36 AM, Ted Lemon  wrote:
> On Jul 31, 2017, at 1:02 AM, Mark Andrews  wrote:
>
> The delegatation is INSECURE and SIGNED not UNSIGNED.  The wording
> here is *important*.
>
>
> Can you explain what the distinction is, and what the problem is that you
> see in point five?   The reason I ask is that we explicitly changed the
> wording from "insecure" to "not signed" because someone else said that it
> wasn't clear what "insecure" meant.   It seems to me that the current
> language is explicit and unambigious; I think this is better than being
> "correct."   So what is the bad outcome that might occur as a result of
> using the term "not signed" rather than "insecure"?


Having recently had exactly this discussion with someone, this area is
fraught with opportunities for misunderstandings.

Let's take example.com as an example[0]. The .com zone is signed.
Example Corp hired a DNS geek, who signed the example.com zone, but
never quite got around to publishing a DS record in the parent.

There is now a signed, insecure delegation to a signed zone; the
delegation itself is signed (.com is a signed zone and so there there
is an RRSIG for the NS for example.com), but there is no DS record, so
it is insecure.

It really is an insecure delegation, not an unsigned delegation --
calling it unsigned would be confusing to many people. The person I
was discussing it with wasn't aware of the term "insecure delegation"
and assumed that it meant an "unsigned delegation", which is, um,
difficult to achieve in a non-NSEC3 OO zone...

I spend an almost infinite amount of time[1] trying to explain this
very point (to someone who understands DNSEEC) over the phone - it's
tricky to communicate without a whiteboard and / or diagram.
I ended up opening an issue on the terminology-bis document to get it
added: 
https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/26#issuecomment-314275871


W
[0]: For the purpose of discussion, let's pretend that .COM uses NSEC,
not NSEC3 with Opt-Out.
[1]: Ok, perhaps it wasn't almost infinite, but it sure felt like it...

>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-07-31 Thread Ted Lemon 
On Jul 31, 2017, at 1:02 AM, Mark Andrews  wrote:
> The delegatation is INSECURE and SIGNED not UNSIGNED.  The wording
> here is *important*.

Can you explain what the distinction is, and what the problem is that you see 
in point five?   The reason I ask is that we explicitly changed the wording 
from "insecure" to "not signed" because someone else said that it wasn't clear 
what "insecure" meant.   It seems to me that the current language is explicit 
and unambigious; I think this is better than being "correct."   So what is the 
bad outcome that might occur as a result of using the term "not signed" rather 
than "insecure"?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-07-30 Thread Mark Andrews 

DNSSEC describes the delegation as "insecure".

Old:
   In addition, it's necessary, for compatibility with DNSSEC
   (Section 6), that an unsigned delegation be present for the name.
   There is an existing process for allocating names under '.arpa'
   [RFC3172].  No such process is available for requesting a similar
   delegation in the root at the request of the IETF, which does not
   administer that zone.  As a result, the use of '.home' is deprecated.

New:
   In addition, it's necessary, for compatibility with DNSSEC
   (Section 6), that an insecure delegation be present for the name.
   There is an existing process for allocating names under '.arpa'
   [RFC3172].  No such process is available for requesting a similar
   delegation in the root at the request of the IETF, which does not
   administer that zone.  As a result, the use of '.home' is deprecated.


Paragraph 5 doesn't read well and won't match reality once the
insecure delegation of home.arpa is in place.

   5.  No special processing of 'home.arpa.' is required for
   authoritative DNS server implementations.  It is possible that an
   authoritative DNS server might attempt to check the authoritative
   servers for 'home.arpa.' for a delegation beneath that name
   before answering authoritatively for such a delegated name.  In
   such a case, because the name always has only local significance
   there will be no such delegation in the 'home.arpa.' zone, and so
   the server would refuse to answer authoritatively for such a
   zone.  A server that implements this sort of check MUST be
   configurable so that either it does not do this check for the
   'home.arpa.' domain, or it ignores the results of the check.


The delegatation is INSECURE and SIGNED not UNSIGNED.  The wording
here is *important*.

Old:

7.  Delegation of 'home.arpa.'

   In order to be fully functional, there must be a delegation of
   'home.arpa.' in the '.arpa.' zone [RFC3172].  This delegation MUST
   NOT be signed, MUST NOT include a DS record, and MUST point to one or
   more black hole servers, for example 'blackhole-1.iana.org.' and
   'blackhole-2.iana.org.'.  The reason that this delegation must not be
   signed is that not signing the delegation breaks the DNSSEC chain of
   trust, which prevents a validating stub resolver from rejecting names
   published under 'home.arpa.' on a homenet name server.

New:

7.  Delegation of 'home.arpa.'

   In order to be fully functional, there must be a delegation of
   'home.arpa.' in the '.arpa.' zone [RFC3172].  This delegation
   MUST be insecure, MUST NOT include a DS record, and MUST point
   to one or more black hole servers, for example 'blackhole-1.iana.org.'
   and 'blackhole-2.iana.org.'.  The reason that this delegation
   must be insecure is that it breaks the DNSSEC chain of trust,
   which prevents a validating stub resolver from rejecting names
   published under 'home.arpa.' on a homenet name server.



-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] I-D Action: draft-ietf-homenet-dot-10.txt

2017-07-28 Thread internet-drafts 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Home Networking WG of the IETF.

Title   : Special Use Domain 'home.arpa.'
Authors : Pierre Pfister
  Ted Lemon
Filename: draft-ietf-homenet-dot-10.txt
Pages   : 9
Date: 2017-07-28

Abstract:
   This document specifies the behavior that is expected from the Domain
   Name System with regard to DNS queries for names ending with
   '.home.arpa.', and designates this domain as a special-use domain
   name. 'home.arpa.' is designated for non-unique use in residential
   home networks.  Home Networking Control Protocol (HNCP) is updated to
   use the 'home.arpa.' domain instead of '.home'.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-homenet-dot-10
https://datatracker.ietf.org/doc/html/draft-ietf-homenet-dot-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dot-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet