Skip to Content.
Sympa Menu

technical-discuss - Re: [InC-Technical] InCommon Baseline Expectations Metadata Requirements

Subject: InCommon Technical Discussions

List archive

Re: [InC-Technical] InCommon Baseline Expectations Metadata Requirements


Chronological Thread 
  • From: Nick Roy <>
  • To:
  • Subject: Re: [InC-Technical] InCommon Baseline Expectations Metadata Requirements
  • Date: Fri, 10 Nov 2017 14:09:43 -0700
  • Authentication-results: spf=none (sender IP is ) ;
  • Ironport-phdr: 9a23:8w+UAxLrybd8pEeM99mcpTZWNBhigK39O0sv0rFitYgeIvjxwZ3uMQTl6Ol3ixeRBMOAuqIC07KempujcFRI2YyGvnEGfc4EfD4+ouJSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgppPOT1HZPZg9iq2+yo9ZDeZwZFiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLdQgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QLYpUjqg8qhrUgflhjoZOT438G/ZicJ+g6xUrx2juxNxzI/UbZqJNPd9ZK7RYc8WSGRDU8tXSidPApm8b4wKD+cZJehYrpXyp1gTphWiAgmtBP7kxzhOhn/s2q070/8sEQDA3Aw8Ad0OqnLUo8vpNKsMS+y60rTHzSjaYv5QxDzz5o/IchU7rvGNW7J9acvRyU8zFwzblFWQr5LqPy+L2ugXrWeU8vdgWfqhi2E9tw5+vCOgxsArionKnI4a1lfE9SB/zY0oJtO4UFZ2bcO4HJZfrS2XOIl7TtktTm10oio3zqAKtYamcCULxpkr3QDTZvyJfoSS7R/uW/ydLDl6iX9jZbmxnQy98VK6xe35TsS00EhFri5CktTUrn4Ayxvd5tSJR/dk4EqvwCuD2xnU6u5fP084j63bK4M9wrErkZoTrELDETLslEXulq+WcVkk9fa05OT7Y7XmoZmcO5VzigHjLqQunsu/AeM7MgQUQ2eb/uG82KXi/U3/XrpKkuU7nrTFvJ3VP8gWqay0DxVa34o/8RqyCyqq3MwdnXYdLVJFfByHj5LuO1HLOP34C+2/g1OskTpwxvDGOKHhDYvXLnjFjrjhYahx51RCxwUu0NBT/4hUBa0ZIPLvRk/xs8TVDh4/MwOoxObnDdB91oQYWW6VBa+ZKqzSvUaU5u0xP+aMZIkVuDfhJPc/4/7ilGI2mV4Gfaa1wJsXc2u4E+9iI0WYenrsnswBHXkQsgo/SuzqlEONUSRVZ3msQ6Iw+Cs3B5y7AofeFciRh+md0Sy7GJxdb2QDBlGXGmrzbK2FXfwLbSeVJIlmiDNXe6KmTtoH1Bqt/DX92vIzKPDT6wUZs47uzt54+7eVmB0vo28nR/+B2n2AGjkn1lgDQCU7ifhy
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

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




Archive powered by MHonArc 2.6.19.

Top of Page