InCommon Technical Discussions

[David Langenberg <>]

There's other ways to check for compliance, you could spend some staff time on a random sample for instance.  Tell folks that we audit randomly.  I imagine it wouldn't take too long to run xslt | wget to get a chunk of logos and then breeze through them flagging the bad actors.  When it comes to enforcement, you're gonna have the same staff costs whether it's done up-front or after a complaint.  If the accused chooses to defend/appeal it's expensive no matter how the violation was discovered.

Dave

--

David Langenberg

Asst. Director, Identity Management

The University of Chicago

---

From: Nick Roy <>
Sent: Monday, November 13, 2017 6:02:34 PM
To: David Langenberg; Farmer, Jacob;
Subject: Re: [InC-Technical] InCommon Baseline Expectations Metadata Requirements

 

Things that are required and not enforced mechanically/procedurally inevitably turn into something someone wants enforced in the longer term.  The question will get asked, "why do you guys require X but you don't check for it?" and then I have to figure out how to check for it.

Going and beating someone over the head with rules is a manual process that takes time (AAC or staff or others).  I'd like as little room for interpretation and as much possibility for automation as possible in this set of requirements.

Nick

On 11/13/17 4:58 PM, David Langenberg wrote:

Does every requirement need a technical check or a pre-emptive check?  Why not just state it & wait for someone to complain?  Then you can go beat the bad-actor with the regs.

Dave

--

David Langenberg

Asst. Director, Identity Management

The University of Chicago

---

From: on behalf of Nick Roy
Sent: Monday, November 13, 2017 3:59:21 PM
To: Farmer, Jacob;
Subject: Re: [InC-Technical] InCommon Baseline Expectations Metadata Requirements

 

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: [] 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" 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:
>>>     >     [] 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
>>>     >     >
>>>     >     >
>>>     >    
>>>     >    
>>>    
>>>    
>>>