InCommon Technical Discussions

[Nick Roy <>]

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
>     >     >
>     >     >
>     >     
>     >     
>     
>     
>