Subject: [pkix] FW: [cabfpub] "Authorized Port"

From: Ben Wilson <[email-masked]>
Date: Fri, 4 Sep 2015 15:15:11 +0000

Forwarding to this list for additional input.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Wilson
Sent: Friday, September 4, 2015 9:03 AM
To: Gervase Markham <[email-masked]>; Ryan Sleevi ([email-masked]) <[email-masked]>; CABFPub <[email-masked]>
Subject: Re: [cabfpub] "Authorized Port"

This is good discussion.  Let's keep it up.  We need more people to chime in.

-----Original Message-----
From: Gervase Markham [mailto:[email-masked]]
Sent: Friday, September 4, 2015 2:34 AM
To: Ben Wilson <[email-masked]>; CABFPub <[email-masked]>
Subject: Re: [cabfpub] "Authorized Port"

>On 03/09/15 18:06, Ben Wilson wrote:
>> The Validation Working Group is considering amendments to the domain 
>> validation processes.  Two of those processes use the concept of an 
>> “authorized port” in order to limit the threat of approvals occurring 
>> through ports that are not “well-known”.

> Why would one want to permit approvals for an SSL certificate through a port 
> which was well-known for not being SSL?

> Is this because of STARTTLS and equivalents?

> I also agree with Ryan that control of any port over 1024 should not be considered to 
> be the same as control of the server or the FQDN which points to it.

> Gerv

>>> All,

>>> The Validation Working Group is considering amendments to the domain validation processes.  
>>> Two of those processes use the concept of an “authorized port” in order to limit the threat of 
>>> approvals occurring through ports that are not “well-known”.  
>>> Here is the relevant language of the draft ballot:
>>>
>>> 6. Having the Applicant demonstrate control over the requested FQDN by installing a Random Value 
>>> (contained in the name of the file, the content of a file, on a web page in the form of a meta tag, or 
>>> any other format as determined by the CA) under "/.well-known/validation" directory on an Authorized 
>>> Domain Name that can be validated over an Authorized Port;
>>> … 
>>> 9. Having the Applicant demonstrate control over the FQDN by the Applicant requesting and then 
>>> installing a Test Certificate issued by the CA on the FQDN which is accessed and then validated via 
>>> https by the CA over an Authorized Port;

>>> I have argued in support of at least the following ports:

>>> Authorized Ports	Not SSL/TLS	SSL/TLS	
 	 	 	
>>> ftp			20-21		989-990	
>>> ssh			22	 	
>>> telnet			23		992	
>>> smtp			25, 587		465	
>>> http			80		443	
>>> pop			110		995	
>>> nntp			119		563	
>>> imap			143		993	
>>> irc			194		994	
>>> ldap			389		636	
>>> sip			5060		5061	
			
>>> Sample of ports that wouldn't be included (among 1,000s of others)	 		
>>> sftp	115		
>>> active-directory	445		
>>> rfs	556		
>>> filemaker	591		
>>> rpc-over-http	593		
>>> ieee-mms-ssl	695		
>>> kerberos	749-752		
>>> brocade-ssl	898		
>>> vmware  	901-904		
>>> ibm	1364		
>>> c-panel	2083		
			
>>> In a written list I included port 24 (private mail) and 991 (network news) because 
>>> they were consecutive within a series below for the definition of “Authorized Port”– 
>>>
>>> “ “Authorized Port” means ports 20-25, 80, 110, 119, 143, 194, 389, 443, 465, 
>>> 563, 587, 636, 989-995.”

>>> I’ve told the Validation Working Group that I think we need to reach outside 
>>> the Validation WG to confirm whether this limited list is of the right scope.  

>>> If you have any opinions, please respond.

>>> Thanks,

>>> Ben