InCommon Technical Discussions

[Nick Roy <>]

I didn't include it since I there is no way that InCommon could check
for that kind of thing in an easily automatable way.  When you start
asking us to use tensorflow to analyze images, then I need to look at a
different kind of hiring.  ;-)

Nick

On 11/13/17 11:33 AM, Farmer, Jacob wrote:
> Nick,
>
> Thanks for posting the revision. It does not seem to include the 
> information Dave shared from the Facebook policy. I think that would be 
> useful clarification to have; by IU's brand standards, we would be required 
> to use either a red or white background and I think Facebook's guidance 
> about using a colored background or colored border is a good revision to 
> add to the InCommon standard.
>
> Also, I completely agree with having a standardized dimension, but I am not 
> sure where this exact dimension came from. Has there been a survey done of 
> widely-used identity selectors to make sure that resolution is commonly 
> used? (and it's entirely possible this was done and I just missed that part 
> of the thread)
>
> Jacob
>
> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Nick Roy
> Sent: Friday, November 10, 2017 4:10 PM
> To: 
> 
> Subject: Re: [InC-Technical] InCommon Baseline Expectations Metadata 
> Requirements
>
> Here's an updated version of the wiki, please review:
>
> https://spaces.internet2.edu/x/4RL9Bg
>
> Nick
>
> On 11/10/17 8:52 AM, Nick Roy wrote:
>> Nice
>>
>> I'm going to collate all the info from this discussion and update the 
>> wiki page and our internal gdoc with the info today.
>>
>> Nick
>>
>> On 11/10/17 8:35 AM, David Shafer wrote:
>>> FYI, here is Facebook’s policy for app icons, which seems to work pretty 
>>> well:
>>>
>>> “4. Icons:
>>> a. Use a transparent or colored background. If your icon requires a white 
>>> background, use a colored border. 
>>> b. If your logo has a drop shadow, use a colored background.”
>>>
>>> https://developers.facebook.com/policy/
>>>
>>> Dave
>>>
>>> -----Original Message-----
>>> From: 
>>> <>
>>>  on behalf of Nick Roy 
>>> <>
>>> Date: Thursday, November 9, 2017 at 4:05 PM
>>> To: Chris Phillips 
>>> <>,
>>>  "Farmer, Jacob" 
>>> <>,
>>>  "Cantor, Scott" 
>>> <>,
>>>  
>>> ""
>>>  
>>> <>
>>> Subject: Re: [InC-Technical] InCommon Baseline Expectations Metadata 
>>> Requirements
>>>
>>>     I'll point out that the SSL test is a *recommended* piece but *not
>>>     required* in the current specification of Baseline Expectations.
>>>     
>>>     To restate what I've heard so far:
>>>     
>>>     Logo URL:
>>>     
>>>     - results in a 200 via HTTP GET
>>>     - is a PNG with a transparent background / alpha channel (because JPG
>>>     does not support transparency)
>>>     - is 80w x 20h
>>>     
>>>     SSL for endpoints:
>>>     
>>>     - subject to InCommon operations' running of SSL scans (exact nature 
>>> to
>>>     be determined by operations)
>>>     - operations may save and act on information about the quality of SSL 
>>> at
>>>     its discretion
>>>     
>>>     (no minimum grade or other requirement related to SSL)
>>>     
>>>     errorURL:
>>>     
>>>     - results in a 200 via HTTP GET, other results cause a warning but 
>>> not a
>>>     full failure of the baseline tests
>>>     (do we need to say something about 302 and maximum depth to chase
>>>     referrals before lack of a 200 causes failure?)
>>>     
>>>     How does that look?
>>>     
>>>     Thank you,
>>>     
>>>     Nick
>>>     
>>>     On 11/9/17 8:47 AM, Chris Phillips wrote:
>>>     > Great dialogue on this.
>>>     >
>>>     > Maybe it would be better to define what’s not acceptable regarding 
>>> a grade and what’s a reasonable duration to remediate.
>>>     >
>>>     > Highest grade (A+) preferred but no lower than C on ssllabs and no 
>>> longer than say X days below this band of acceptance.
>>>     >
>>>     > This gives latitude to maneuver when the tools change underneath 
>>> one’s feet and dependencies to catch up. 
>>>     > Jacob’s example is great in this regard. If his group didn’t care 
>>> about it (or know to test that way) then how would he have pushed for the 
>>> change to get back into compliance and hence pressured the vendor to step 
>>> up?
>>>     >
>>>     > That said, things like Poodle SSLv3 and other future events we know 
>>> will happen will change ranking from A+ to F overnight. Using the idea of 
>>> X days to come into compliance allows us to respond commensurate with the 
>>> risk.  It also allows us to simply be users of the tool which is not our 
>>> core mission – we just want the output to inform our decisions.
>>>     >
>>>     >
>>>     > C
>>>     >
>>>     > On 2017-11-09, 9:53 AM, "Farmer, Jacob" 
>>> <
>>>  on behalf of 
>>> >
>>>  wrote:
>>>     >
>>>     >     Nick,
>>>     >     
>>>     >     I like the Qualys SSL scanner and we use it often. Given my 
>>> history, though, I 
>>>     >     am reluctant to rely on it for this kind of thing. A real-world 
>>> story from the 
>>>     >     last few years: Qualys made a change to the scanner which 
>>> caused sites we 
>>>     >     manage that were in the A range to fall into the B+ range. I 
>>> don't recall all 
>>>     >     of the details about why; I think it had to do with cipher 
>>> suites. Our load 
>>>     >     balancer -- a widely deployed product on its current version -- 
>>> could not be 
>>>     >     adjusted to bring it back up to A. There was something in the 
>>> configuration 
>>>     >     that Qualys simply didn't like and there was no way to fix it 
>>> until a vendor 
>>>     >     patch shipped.
>>>     >     
>>>     >     I'm glad that we took the time to get it figured out, but I 
>>> also don't think 
>>>     >     that the quality of SSL was meaningfully degraded in the 
>>> interim.
>>>     >     
>>>     >     I support the idea of defining "good TLS" but I am reluctant to 
>>> rely on this 
>>>     >     scanner to define it.
>>>     >     
>>>     >     Jacob
>>>     >     
>>>     >     -----Original Message-----
>>>     >     From: 
>>> 
>>>  
>>>     >     
>>> [mailto:]
>>>  On Behalf Of Nick Roy
>>>     >     Sent: Wednesday, November 8, 2017 4:59 PM
>>>     >     To: Cantor, Scott 
>>> <>;
>>>  
>>> 
>>>     >     Subject: Re: [InC-Technical] InCommon Baseline Expectations 
>>> Metadata 
>>>     >     Requirements
>>>     >     
>>>     >     
>>>     >     
>>>     >     On 11/8/17 1:58 PM, Cantor, Scott wrote:
>>>     >     >> RECOMMENDED:
>>>     >     >>
>>>     >     >>    SSL certificates on endpoints are valid
>>>     >     > That seems like a slippery slope: valid re: dates? Specific 
>>> CAs? Key sizes? 
>>>     >     > What about ciphers, or use of TLS 1.0, etc.?
>>>     >     >
>>>     >     > Requiring a logo is, I think, underspecified, we should 
>>> mandate specific 
>>>     >     > size(s).
>>>     >     >
>>>     >     > I'd like to see errorURL be required with guidance around 
>>> what should be 
>>>     >     > behind it.
>>>     >     
>>>     >     We think errorURL should be included as well, but since it was 
>>> not part of the 
>>>     >     'required' elements that AAC specified (AAC assumed errorURL 
>>> was part of the 
>>>     >     mdui: information, and it is not) that means this would have to 
>>> go back to ACC 
>>>     >     to make errorURL a separate required element.
>>>     >     
>>>     >     Agree re: specific requirements for SSL and logo.
>>>     >     
>>>     >     Here is my proposed requirement for SSL for endpoints (since 
>>> it's recommended 
>>>     >     but not required):
>>>     >     
>>>     >     - Achieve a grade of A on the Qualys SSL scanner [1]
>>>     >     
>>>     >     And for HTTPS Logo URL:
>>>     >     
>>>     >     - Must result in an HTTP 200 in response to a GET request
>>>     >     - Image must be either a PNG or JPG
>>>     >     - Image must be 80 pixels in width by 60 in height
>>>     >     
>>>     >     [1] 
>>> https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide
>>>     >     
>>>     >     Let me know if you think this is something that would better be 
>>> discussed in 
>>>     >     detail by the Ops Advisory Group or in some other venue.
>>>     >     
>>>     >     Thank you,
>>>     >     
>>>     >     Nick
>>>     >     
>>>     >     >
>>>     >     > -- Scott
>>>     >     >
>>>     >     >
>>>     >     
>>>     >     
>>>     
>>>     
>>>