Re: [cabfpub] [Ext] BR Authorized Ports, add 8443
From: Ryan Sleevi [mailto:sle...@google.com] Sent: Friday, March 2, 2018 11:22 AM To: Phillip <phill...@comodo.com> Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>; Paul Hoffman <paul.hoff...@icann.org>; Ben Wilson <ben.wil...@digicert.com> Subject: Re: [cabfpub] [Ext] BR Authorized Ports, add 8443 More importantly though, how many validation approaches do we need? I would rather work on reducing them rather than increasing them further. And 64KB should be enough for everybody, no one will need more than one monitor, XGA is plenty resolution, etc. I would not obsess about the number of validation methods, I would rather us focus on ensuring a consistent level of assurance, and then work to help ensure that anyone and everyone on the Web can easily get a certificate and facilitate greater adoption of encryption. Unlike 640K, a cryptographic digest is actually sufficient to authenticate any sequence of bits. Since we require that any validation mechanism be described objectively, it follows that it can be described as a sequence of bits and thus that a cryptographic digest is sufficient. So I am pretty sure that we can use a CAA record as the hook for pretty much any new validation mechanism we might propose. But as Ryan is pointing out, such mechanisms are not necessarily good ones or ones we should accept. To be more precise in what was concerning me: I think that we should attempt to limit the number of Internet services, accounts, etc. that operators need to be concerned about restricting access to in order to prevent a malicious request for validation. This is the concern that makes port 8443 unacceptable to me. Most of the billions of hosts on the net do not regard that port as privileged so we should not attempt to make it so. Rather than adding to the ports, accounts, etc. that we are requiring people to watch, I would like us to choose one affordance that has been created for the express purpose of being a gating point for issue. That is the CAA record. If we need more flexibility in issue mechanisms, the most flexible approach I know of is to use a public key to validate the request. And I already use UDFs to authenticate public keys. There clearly needs to be some part of any validation mechanism for a DNS based protocol that uses information that comes either directly or indirectly from the DNS system. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [Ext] BR Authorized Ports, add 8443
For sure. Apologies if that was worded confusing - we're hugely supportive of SRVNames, but solving the technical and policy issues around them is thorny and will require technical expertise, and I think most of the technical expertise of the Forum has been otherwise occupied by a number of more pressing matters (adoption of Certificate Transparency, strengthening of validation methods, reducing certificate lifetimes, etc) On Fri, Mar 2, 2018 at 11:20 AM, Tim Hollebeekwrote: > We’re willing to continue talking through those issues in an attempt to > reach a solution. I do think SRVNames would be a useful improvement. For > us, the lack of movement has had more to do with time constraints than > technical constraints! > > > > While SRVNames do offer a way to scope the authority to a particular > service (on any port), there's been no movement towards adopting them in > the CA/Browser Forum, due to the issues they would have with technically > constrained sub-CAs. > ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [Ext] BR Authorized Ports, add 8443
On Fri, Mar 2, 2018 at 11:11 AM, Phillip <phill...@comodo.com> wrote: > ??? I think it is fairly clear that with the necessary privs, I can > request a TCP/IP socket on any port (other than 0) and then bind a TLS > provider to it. > > > > The point I am making is that the fact the subscriber might use the > certificate on port 8443 or for that matter on any port in the range > [1,65535] does not mean that the validation process should allow other > ports. > It sounds like we're in violent agreement here, which is why we have an authorized ports list. > I currently have >40 TCP/IP sockets open on this Windows box and two > thirds of them have https on them. And that is just my development > environment. I suspect most of them are due to Docker or the Linux VMs. > > > > > > More importantly though, how many validation approaches do we need? I > would rather work on reducing them rather than increasing them further. > And 64KB should be enough for everybody, no one will need more than one monitor, XGA is plenty resolution, etc. I would not obsess about the number of validation methods, I would rather us focus on ensuring a consistent level of assurance, and then work to help ensure that anyone and everyone on the Web can easily get a certificate and facilitate greater adoption of encryption. > In particular, I would like CAA to become a one stop shop for telling CAs > what they need to issue a cert. For example: > OK, at least it's easier to know where we disagree. > > > example.com. IN CAA 0 issue "comodoca.com" > > example.com. IN CAA 128 udf "MDTXA-Y7DQJ-P7IRF-XUCRE- > 2Y5TH-RVNHP" > > > > The above record would prevent a CA from issuing a cert unless they > understand the semantics of the UDF record. So this is the only validation > approach permitted. > > > > The UDF record requires that any cert request be signed or countersigned > according to a security policy that has the UDF fingerprint > "MDTXA-Y7DQJ-P7IRF-XUCRE-2Y5TH-RVNHP" > > > > These are described here. > > > > https://tools.ietf.org/html/draft-hallambaker-udf-08 > > > > > > *From:* Ryan Sleevi [mailto:sle...@google.com] > *Sent:* Friday, March 2, 2018 10:52 AM > *To:* Phillip <phill...@comodo.com>; CA/Browser Forum Public Discussion > List <public@cabforum.org> > *Cc:* Paul Hoffman <paul.hoff...@icann.org>; Ben Wilson < > ben.wil...@digicert.com> > > *Subject:* Re: [cabfpub] [Ext] BR Authorized Ports, add 8443 > > > > > > > > On Fri, Mar 2, 2018 at 10:35 AM, Phillip via Public <public@cabforum.org> > wrote: > > To clarify what Paul said, > > We need to distinguish between the use of a port for certificate validation > and the use of a port for delivery of an Internet service. The fact that we > use SSL on every port to provide a service does not mean that we should > allow that use for validation. > > > > On what basis do you make this claim? I see no justification for the > distinction, nor support for the 'fact'. > > > > I do think we should consider adding a DNS prefix for certificate > validation > though because ports are the old way to advertise services and does not > scale. We ran out of ports a long time ago and now use DNS prefixes and > .well-known HTTP services to extend the port numbers. > > > -Original Message- > From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Paul > Hoffman > via Public > Sent: Friday, March 2, 2018 10:08 AM > To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public > Discussion > List <public@cabforum.org> > > Subject: Re: [cabfpub] [Ext] BR Authorized Ports, add 8443 > > On Mar 1, 2018, at 7:51 AM, Ben Wilson via Public <public@cabforum.org> > wrote: > > > > Forwarding from Richard Wang: > > > > The current BRs say: > > > > Authorized Ports: One of the following ports: 80 (http), 443 (http), 25 > (smtp), 22 (ssh). > > > > But many internal networks use the port 8443, broadly used in Apache > server, today, one of our customers uses this port and can't change to use > another port, I wish you can help to add this port 8443 to be allowed in > the > BRs, thanks. > > It appears that the BRs currently are talking about authorizing *services*, > not ports. That is, I would not expect to be able to put a HTTP server on > port 22 on my system and have that considered authorized by the BRs. > > Any Internet service can be run on any port. Every web, SMTP, and SSH > server > software configuration allows you to run on the standard ports or any por
Re: [cabfpub] [Ext] BR Authorized Ports, add 8443
We’re willing to continue talking through those issues in an attempt to reach a solution. I do think SRVNames would be a useful improvement. For us, the lack of movement has had more to do with time constraints than technical constraints! While SRVNames do offer a way to scope the authority to a particular service (on any port), there's been no movement towards adopting them in the CA/Browser Forum, due to the issues they would have with technically constrained sub-CAs. smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [Ext] BR Authorized Ports, add 8443
??? I think it is fairly clear that with the necessary privs, I can request a TCP/IP socket on any port (other than 0) and then bind a TLS provider to it. The point I am making is that the fact the subscriber might use the certificate on port 8443 or for that matter on any port in the range [1,65535] does not mean that the validation process should allow other ports. I currently have >40 TCP/IP sockets open on this Windows box and two thirds of them have https on them. And that is just my development environment. I suspect most of them are due to Docker or the Linux VMs. More importantly though, how many validation approaches do we need? I would rather work on reducing them rather than increasing them further. In particular, I would like CAA to become a one stop shop for telling CAs what they need to issue a cert. For example: example.com. IN CAA 0 issue "comodoca.com" example.com. IN CAA 128 udf "MDTXA-Y7DQJ-P7IRF-XUCRE-2Y5TH-RVNHP" The above record would prevent a CA from issuing a cert unless they understand the semantics of the UDF record. So this is the only validation approach permitted. The UDF record requires that any cert request be signed or countersigned according to a security policy that has the UDF fingerprint "MDTXA-Y7DQJ-P7IRF-XUCRE-2Y5TH-RVNHP" These are described here. https://tools.ietf.org/html/draft-hallambaker-udf-08 From: Ryan Sleevi [mailto:sle...@google.com] Sent: Friday, March 2, 2018 10:52 AM To: Phillip <phill...@comodo.com>; CA/Browser Forum Public Discussion List <public@cabforum.org> Cc: Paul Hoffman <paul.hoff...@icann.org>; Ben Wilson <ben.wil...@digicert.com> Subject: Re: [cabfpub] [Ext] BR Authorized Ports, add 8443 On Fri, Mar 2, 2018 at 10:35 AM, Phillip via Public <public@cabforum.org <mailto:public@cabforum.org> > wrote: To clarify what Paul said, We need to distinguish between the use of a port for certificate validation and the use of a port for delivery of an Internet service. The fact that we use SSL on every port to provide a service does not mean that we should allow that use for validation. On what basis do you make this claim? I see no justification for the distinction, nor support for the 'fact'. I do think we should consider adding a DNS prefix for certificate validation though because ports are the old way to advertise services and does not scale. We ran out of ports a long time ago and now use DNS prefixes and .well-known HTTP services to extend the port numbers. -Original Message- From: Public [mailto:public-boun...@cabforum.org <mailto:public-boun...@cabforum.org> ] On Behalf Of Paul Hoffman via Public Sent: Friday, March 2, 2018 10:08 AM To: Ben Wilson <ben.wil...@digicert.com <mailto:ben.wil...@digicert.com> >; CA/Browser Forum Public Discussion List <public@cabforum.org <mailto:public@cabforum.org> > Subject: Re: [cabfpub] [Ext] BR Authorized Ports, add 8443 On Mar 1, 2018, at 7:51 AM, Ben Wilson via Public <public@cabforum.org <mailto:public@cabforum.org> > wrote: > > Forwarding from Richard Wang: > > The current BRs say: > > Authorized Ports: One of the following ports: 80 (http), 443 (http), 25 (smtp), 22 (ssh). > > But many internal networks use the port 8443, broadly used in Apache server, today, one of our customers uses this port and can't change to use another port, I wish you can help to add this port 8443 to be allowed in the BRs, thanks. It appears that the BRs currently are talking about authorizing *services*, not ports. That is, I would not expect to be able to put a HTTP server on port 22 on my system and have that considered authorized by the BRs. Any Internet service can be run on any port. Every web, SMTP, and SSH server software configuration allows you to run on the standard ports or any port you choose. Two suggestions: - Clarify the BRs to say "Authorized Services and Ports" - Add text that says only the authorized ports may be used If CABF folks want to allow issuance of certificates for services on ports other than the standard ports, you will have to decide what it means to initially offer a service on one part and then move it to another port. The PKIX standard does not allow encoding of port numbers for services in certificates. --Paul Hoffman ___ Public mailing list Public@cabforum.org <mailto:Public@cabforum.org> https://cabforum.org/mailman/listinfo/public ___ Public mailing list Public@cabforum.org <mailto:Public@cabforum.org> https://cabforum.org/mailman/listinfo/public ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [Ext] BR Authorized Ports, add 8443
On Fri, Mar 2, 2018 at 10:35 AM, Phillip via Public <public@cabforum.org> wrote: > To clarify what Paul said, > > We need to distinguish between the use of a port for certificate validation > and the use of a port for delivery of an Internet service. The fact that we > use SSL on every port to provide a service does not mean that we should > allow that use for validation. > On what basis do you make this claim? I see no justification for the distinction, nor support for the 'fact'. > I do think we should consider adding a DNS prefix for certificate > validation > though because ports are the old way to advertise services and does not > scale. We ran out of ports a long time ago and now use DNS prefixes and > .well-known HTTP services to extend the port numbers. > > > -Original Message- > From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Paul > Hoffman > via Public > Sent: Friday, March 2, 2018 10:08 AM > To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public > Discussion > List <public@cabforum.org> > Subject: Re: [cabfpub] [Ext] BR Authorized Ports, add 8443 > > On Mar 1, 2018, at 7:51 AM, Ben Wilson via Public <public@cabforum.org> > wrote: > > > > Forwarding from Richard Wang: > > > > The current BRs say: > > > > Authorized Ports: One of the following ports: 80 (http), 443 (http), 25 > (smtp), 22 (ssh). > > > > But many internal networks use the port 8443, broadly used in Apache > server, today, one of our customers uses this port and can't change to use > another port, I wish you can help to add this port 8443 to be allowed in > the > BRs, thanks. > > It appears that the BRs currently are talking about authorizing *services*, > not ports. That is, I would not expect to be able to put a HTTP server on > port 22 on my system and have that considered authorized by the BRs. > > Any Internet service can be run on any port. Every web, SMTP, and SSH > server > software configuration allows you to run on the standard ports or any port > you choose. > > Two suggestions: > > - Clarify the BRs to say "Authorized Services and Ports" > > - Add text that says only the authorized ports may be used > > If CABF folks want to allow issuance of certificates for services on ports > other than the standard ports, you will have to decide what it means to > initially offer a service on one part and then move it to another port. The > PKIX standard does not allow encoding of port numbers for services in > certificates. > > --Paul Hoffman > ___ > Public mailing list > Public@cabforum.org > https://cabforum.org/mailman/listinfo/public > > ___ > Public mailing list > Public@cabforum.org > https://cabforum.org/mailman/listinfo/public > ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [Ext] BR Authorized Ports, add 8443
On Fri, Mar 2, 2018 at 10:08 AM, Paul Hoffman via Public < public@cabforum.org> wrote: > On Mar 1, 2018, at 7:51 AM, Ben Wilson via Public> wrote: > > > > Forwarding from Richard Wang: > > > > The current BRs say: > > > > Authorized Ports: One of the following ports: 80 (http), 443 (http), 25 > (smtp), 22 (ssh). > > > > But many internal networks use the port 8443, broadly used in Apache > server, today, one of our customers uses this port and can't change to use > another port, I wish you can help to add this port 8443 to be allowed in > the BRs, thanks. > > It appears that the BRs currently are talking about authorizing > *services*, not ports. That is, I would not expect to be able to put a HTTP > server on port 22 on my system and have that considered authorized by the > BRs. > That is intentionally permitted. > > Any Internet service can be run on any port. Every web, SMTP, and SSH > server software configuration allows you to run on the standard ports or > any port you choose. > > Two suggestions: > > - Clarify the BRs to say "Authorized Services and Ports" > > - Add text that says only the authorized ports may be used > > If CABF folks want to allow issuance of certificates for services on ports > other than the standard ports, you will have to decide what it means to > initially offer a service on one part and then move it to another port. The > PKIX standard does not allow encoding of port numbers for services in > certificates. > The port is, I think, a misdirect, since relying party software is generally ambivalent about the port in use. While SRVNames do offer a way to scope the authority to a particular service (on any port), there's been no movement towards adopting them in the CA/Browser Forum, due to the issues they would have with technically constrained sub-CAs. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [Ext] BR Authorized Ports, add 8443
To clarify what Paul said, We need to distinguish between the use of a port for certificate validation and the use of a port for delivery of an Internet service. The fact that we use SSL on every port to provide a service does not mean that we should allow that use for validation. I do think we should consider adding a DNS prefix for certificate validation though because ports are the old way to advertise services and does not scale. We ran out of ports a long time ago and now use DNS prefixes and .well-known HTTP services to extend the port numbers. -Original Message- From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Paul Hoffman via Public Sent: Friday, March 2, 2018 10:08 AM To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public Discussion List <public@cabforum.org> Subject: Re: [cabfpub] [Ext] BR Authorized Ports, add 8443 On Mar 1, 2018, at 7:51 AM, Ben Wilson via Public <public@cabforum.org> wrote: > > Forwarding from Richard Wang: > > The current BRs say: > > Authorized Ports: One of the following ports: 80 (http), 443 (http), 25 (smtp), 22 (ssh). > > But many internal networks use the port 8443, broadly used in Apache server, today, one of our customers uses this port and can't change to use another port, I wish you can help to add this port 8443 to be allowed in the BRs, thanks. It appears that the BRs currently are talking about authorizing *services*, not ports. That is, I would not expect to be able to put a HTTP server on port 22 on my system and have that considered authorized by the BRs. Any Internet service can be run on any port. Every web, SMTP, and SSH server software configuration allows you to run on the standard ports or any port you choose. Two suggestions: - Clarify the BRs to say "Authorized Services and Ports" - Add text that says only the authorized ports may be used If CABF folks want to allow issuance of certificates for services on ports other than the standard ports, you will have to decide what it means to initially offer a service on one part and then move it to another port. The PKIX standard does not allow encoding of port numbers for services in certificates. --Paul Hoffman ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] [Ext] BR Authorized Ports, add 8443
On Mar 1, 2018, at 7:51 AM, Ben Wilson via Publicwrote: > > Forwarding from Richard Wang: > > The current BRs say: > > Authorized Ports: One of the following ports: 80 (http), 443 (http), 25 > (smtp), 22 (ssh). > > But many internal networks use the port 8443, broadly used in Apache server, > today, one of our customers uses this port and can't change to use another > port, I wish you can help to add this port 8443 to be allowed in the BRs, > thanks. It appears that the BRs currently are talking about authorizing *services*, not ports. That is, I would not expect to be able to put a HTTP server on port 22 on my system and have that considered authorized by the BRs. Any Internet service can be run on any port. Every web, SMTP, and SSH server software configuration allows you to run on the standard ports or any port you choose. Two suggestions: - Clarify the BRs to say "Authorized Services and Ports" - Add text that says only the authorized ports may be used If CABF folks want to allow issuance of certificates for services on ports other than the standard ports, you will have to decide what it means to initially offer a service on one part and then move it to another port. The PKIX standard does not allow encoding of port numbers for services in certificates. --Paul Hoffman ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public