InCommon Technical Discussions

[Chris Phillips <>]

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature