InCommon Technical Discussions

[Nick Roy <>]

On 11/15/17 8:25 AM, Steven Carmody wrote:
> I think InCommon is already past the point where the "profile" of a
> typical installation/site/sysadmin has drastically changed from the
> early days. Growth has brought changes. A major implication of that
> statement is that the type of documentation that IC provides will have
> to change. The TAC was recently discussing whether its now reasonable
> to expect that a campus sysadmin would know how to "create" a local
> proxy server. The errorURL documentation is another example of this
> question -- I believe its exhaustively documented for some sysadmins,
> but under-documented for a growing proportion of the IC member sites.
>
> re "I would suggest that the community start working groups ... to
> determine what the requirements are"
>
> I think that's a great idea, but I'm not aware of any process that
> could be used to do that.
>
> Since this is a Policy Issue, shouldn't the AAC create a WG ?

That seems like the right place to me, but I'm not authoritative on that
in any way.

Nick

>
> On 11/14/17 3:52 PM, Nick Roy wrote:
>> The errorURL is exhaustively documented at:
>>
>> https://spaces.internet2.edu/display/InCFederation/Error+Handling+URL
>>
>> The mdui:PrivacyStatementURL is less thoroughly documented in the
>> following places:
>>
>> IdP:
>> https://spaces.internet2.edu/display/InCFederation/IdP+User+Interface+Elements#IdPUserInterfaceElements-IdPPrivacyStatementURL
>>
>>
>> SP:
>> https://spaces.internet2.edu/display/InCFederation/SP+User+Interface+Elements#SPUserInterfaceElements-SPPrivacyStatementURL
>>
>>
>> The SP privacy statement documentation offers a bit of a chicken-and-egg
>> problem in that it refers to the POP, which will be deprecated by
>> Baseline Expectations.
>>
>> If the community wants guidance on what it expects of itself in these
>> documents, I would suggest that the community start working groups or
>> something to determine what the requirements are.  The 'testables' that
>> InCommon operations will be checking for are merely the existence of the
>> relevant URLs in metadata and that they give an HTTP 200 in response to
>> a GET.
>>
>> Nick
>>
>>
>> On 11/14/17 1:45 PM, Steven Carmody wrote:
>>> 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
>>>>>>       >     >
>>>>>>       >     >
>>>>>>       >
>>>>>>       >
>>>>>>           
>>>>
>>>
>>
>