InCommon Technical Discussions

[Steven Carmody <>]

I assume IC will be providing guidance for both the Privacy Statement 
and the errorURL page ?

I think IC should list the points related to Federated Authentication 
that should be covered in the Privacy Statement, while making it clear 
that this list is a minimum, and other topics can also be addressed.

With the errorURL page, I think IC could be rather specific in its 
suggestions about both content and layout, in order to achieve some 
level of consistency from site to site.

Without some guidance, I think we'll merely repeat our experience with 
the LOGO images.

On 11/10/17 4:09 PM, Nick Roy wrote:
> 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
> > >      >     >
> > >      >     >
> > >      >
> > >      >
> > >      
> > >