Re: [TLS] EXTERNAL: Re: integrity only ciphersuites
Ted Lemon <mellon@fugue.com> Tue, 21 August 2018 16:16 UTC
Return-Path: <mellon@fugue.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC008130E45 for <tls@ietfa.amsl.com>; Tue, 21 Aug 2018 09:16:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaQs0K8o8yss for <tls@ietfa.amsl.com>; Tue, 21 Aug 2018 09:16:17 -0700 (PDT)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5FB130DC3 for <tls@ietf.org>; Tue, 21 Aug 2018 09:16:17 -0700 (PDT)
Received: by mail-io0-x242.google.com with SMTP id y12-v6so6113029ioj.13 for <tls@ietf.org>; Tue, 21 Aug 2018 09:16:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1DFC3feNXQkNDKHm4GrY/FtsQs8nUd5fHonnqfCKrKM=; b=zzChveEG948ivDVP1IB6fAqM3yE5Tvg2lfo3SRjL2LM7TT/DBjOcgBnC0YID+oA8I7 NrR9rWsZ+Mijo09JCEd5l1yh18NHrGcN1Ok5z6iFTYykHbyV9q1E3jKY9B9crZPI2cIC I8J6mdS53m86YeA4W6erWfkjVk0bHGQAqAvxb872+qnSuGdm31dBUKACg94AoOPeZL9G s2c3Gt7jeymzE3dWxV51UqAI5u0YIwwZmSh5GtKddHF+So/mr7nN5OtGFNmy0M3TOt9b mf9oBZZlqTvjroaNsOUpQoo3ZOnNnNVMAd3GH0RrAyegs7a9UkBoq78av91IiS4B9fky W7EQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1DFC3feNXQkNDKHm4GrY/FtsQs8nUd5fHonnqfCKrKM=; b=VLUxUCWN07UUX3C+zEZM8lg3+zzshavs90sjHhT3YYhal8s3P7F6kV1MIyMLAPf4BF /h6xy3ft+tDNtiY2EbNsR1oO8ttXxmRp8XNPayG1o4JtO+xaivuv9yC4dH34NGySWoHI VpjjUTRc0jTp1rXbrA84k8iJdLE9dlpxca1Cu92Uko2whSm0navepFdXC3SYGI5JLnft Fhnsh6xcPyhnkQicSf+dolEVAAeo95CO5JI9qnGQa2uQTNF7KjbfIJ05Ln5pstiVhN0K DkkPRPhC1QnCeHZZ5ZMkjpqlcCeQY3F2nVKqrZ/D/XmgCvTHuiO3XV1a93R/h1vxfqD3 U1fw==
X-Gm-Message-State: AOUpUlFSZlsawvvkFFinIuNOuq37gF5Sc+CNz1SAtJqAYaDhgk5mN+bZ fJ60nIo5l/ZDHUaoDkoLY9iXquqVscP5Kzw0ePQ56A==
X-Google-Smtp-Source: AA+uWPy3cWwN1FbOWO+uH+L3q+8dbdFTY5QB9+etBfmKdKG+jOLcIPkm6E/qCO/BjW/LZld0gQ6b/u856ms+Vrh+c8M=
X-Received: by 2002:a6b:4c5:: with SMTP id 188-v6mr44740123ioe.32.1534868176626; Tue, 21 Aug 2018 09:16:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 09:15:36 -0700 (PDT)
In-Reply-To: <DM5PR2201MB14332BE29A418B74DF8E2AD299310@DM5PR2201MB1433.namprd22.prod.outlook.com>
References: <E29465D4-E4C5-466F-9E3F-240E258DC7C2@cisco.com> <64d23891-2f32-9bb8-1ec8-f4fad13cdfb9@cs.tcd.ie> <982363FD-A839-4175-BA53-7CA242F9ADA6@ll.mit.edu> <2D7F2926-6376-4B2C-BDE9-7A6F1C0FA748@gmail.com> <5B7C1571020000AC0015C330@gwia2.rz.hs-offenburg.de> <DM5PR2201MB14335F5B8FBF5DC0B64B2AEF99310@DM5PR2201MB1433.namprd22.prod.outlook.com> <CAPt1N1=BLy5Y1Ecf6zPbC0UkXKCeKAavtKs=K5u5pL_a6CPtBw@mail.gmail.com> <DM5PR2201MB14332BE29A418B74DF8E2AD299310@DM5PR2201MB1433.namprd22.prod.outlook.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 21 Aug 2018 12:15:36 -0400
Message-ID: <CAPt1N1kBCRw5hES1DA7DDac5GA=LdYeyvyBcaiHOzvsK6ATMyQ@mail.gmail.com>
To: Jack Visoky <jmvisoky@ra.rockwell.com>
Cc: Andreas Walz <andreas.walz@hs-offenburg.de>, "tls@ietf.org" <tls@ietf.org>, "ncamwing=40cisco.com@dmarc.ietf.org" <ncamwing=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000071ff320573f45824"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Zpt9rjmbK5hF9RMrpt3iNmTm9jw>
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Aug 2018 16:16:22 -0000
I asked you if you have any specific devices for which this is an issue. Do you? How did you determine that it was an issue? Do you have A/B testing results on power consumption and/or performance of a null cipher suite versus encryption? On Tue, Aug 21, 2018 at 11:20 AM, Jack Visoky <jmvisoky@ra.rockwell.com> wrote: > Hi Ted, > > > > My apologies for being opaque. There are many different > device/applications/installations so I am sorry if I am mixing ideas > here. Generally the NULL ciphers have the benefit around allowing higher > performance for devices that are lower horsepower. Code space can > certainly be a concern, but I think for industrial applications it’s more > around throughput of high speed I/O, combined with the use cases that > derive little benefit from the confidentiality of this data. “Horsepower” > is of course a vague term in of itself, so here I’m talking about things > that would impact packet processing; this includes processor speed, > available high speed RAM, presence of/lack of crypto acceleration (not in > many Industrial Ethernet devices but growing). I wouldn’t put the > executable code size as high on the list of concerns as these items, > although there are certainly devices that are limited in this. This > horsepower limitation is directly related to the fact that these devices > are expected to function for many years. > > > > I’m happy to clarify any of these points further if needed. > > > > Thanks and Best Regards, > > > > --Jack > > > > *From:* Ted Lemon [mailto:mellon@fugue.com] > *Sent:* Tuesday, August 21, 2018 10:58 AM > *To:* Jack Visoky <jmvisoky@ra.rockwell.com> > *Cc:* Andreas Walz <andreas.walz@hs-offenburg.de>; tls@ietf.org; ncamwing= > 40cisco.com@dmarc.ietf.org > *Subject:* Re: [TLS] EXTERNAL: Re: integrity only ciphersuites > > > > Thanks, Jack, but could you respond to the specific questions that we > asked you? Earlier you were saying that your motivation for using NULL > ciphers was that you had specific hardware that couldn't implement > encryption due to lack of horsepower or memory. Now you seem to be saying > something completely different. It's going to be difficult for us to > understand your requirements if you talk about different things in each > message. > > > > On Tue, Aug 21, 2018 at 10:27 AM, Jack Visoky <jmvisoky@ra.rockwell.com> > wrote: > > (I’m responding a few different points made here) > > > > In general, although this seems like a niche application, there are > actually millions of Industrial Ethernet nodes, with the numbers trending > upward. As mentioned, many of these are relying on older protocols > designed without security in mind. Our industry has had a debate around > using TLS vs. creating something specific. Many of us prefer to rely on > the security benefits of TLS. To another point, although I work for > Rockwell Automation, here I am working in my capacity within ODVA, a > standards group for Industrial Communications that has several large > vendors as members. We have adopted TLS to protect our industrial Ethernet > traffic, and one of the selling points of TLS 1.2 was the ability to use > NULL encryption. > > > > NULL encryption is not really as much about code size but capability of > the devices. The TLS handshake of course contains some “heavyweight” > operations, although handshakes are pretty infrequent as these connections > are often quite long-lived. Once the handshake is over, the I/O data that > is transferred is often quite sensitive to latency, and although the > encryption overhead might not seem like much when the HMAC is considered, > it is still a case where in many applications every bit counts. Regarding > older hardware that exists for many years, some hardware does have > cryptographic acceleration although may not have AES-GCM, rather SHA-256 > HMAC. Alternatively, the hardware might not have any crypto acceleration > as it was designed without TLS in mind. At the same time we’d like to > secure this traffic via a firmware upgrade. Despite this, if using > encryption drops performance enough users will simply not use it, which is > a net worse outcome. Users will likely not upgrade hardware for many years > due to a variety of industry factors. > > > > Kathleen’s comment about defining NULL encryption but being clear about > the risks resonates with me. I’m certainly not suggesting that NULL > encryption is needed in all cases, but there are times (as discussed here > and in the RFC draft) where it could be quite beneficial. > > > > Thanks and Best Regards, > > > > --Jack > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Andreas Walz > *Sent:* Tuesday, August 21, 2018 9:37 AM > *To:* tls@ietf.org > *Cc:* ncamwing=40cisco.com@dmarc.ietf.org > *Subject:* EXTERNAL: Re: [TLS] integrity only ciphersuites > > > > [Use caution with links & attachments] > > > > +1 > > I fully understand the pursuit of minimizing complexity in TLS. However, > banning from TLS all provisions to serve non-internet cases seems > suboptimal to me. > > I think there is a whole universe of systems and applications that are > just at the very beginning of being armed with security features: think of > communication systems driving, e.g., industrial automation and critical > infrastructures. These are quite different from the internet and the web > (different threats, security requirements, architectures, networks, > resources, etc.). Still, IMHO it's not a niche at all; it's just not as > visible to most of us. > > I strongly believe it is *not* a good idea to hold back all the valuable > experience condensed in TLS and entail the design of customized security > protocols for such systems. TLS is state-of-the-art and its benefits should > be accessible to as many systems as possible. > > > > Cheers, > Andi Walz > > > > > >>> Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> 08/21/18 3:20 PM > >>> > > > Sent from my mobile device > > > On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL < > uri@ll.mit.edu> wrote: > > > > "Vulnerable-by-design ciphersuites"? Vulnerable to what? > > > > Suck sites are designed to provide end-point authentication and traffic > integrity. Care to explain/show how these properties would not hold? > > > > Besides, it's been explained several times that some use cases do not > require confidentiality, and in some use cases confidentiality is forbidden. > > I agree with Uri here, flexibility to cover these use cases to accommodate > the actual security requirements may result in them using something instead > of nothing. It could be defined and not listed as Recommended as well. This > comes down to risk management and options, where the risk can be clearly > explained and the lack of recommendation can also be explained. > > Best regards, > Kathleen > > > > > Regards, > > Uri > > > > Sent from my iPhone > > > >> On Aug 21, 2018, at 07:42, Stephen Farrell <stephen.farrell@cs.tcd.ie> > wrote: > >> > >> > >> > >>> On 20/08/18 21:48, Nancy Cam-Winget (ncamwing) wrote: > >>> All, A couple IoT consortiums are trying to embrace the improvements > >>> made to TLS 1.3 and as they define their new security constructs > >>> would like to adopt the latest protocols, in this case TLS 1.3. To > >>> that extent, they have a strong need for mutual authentication, but > >>> integrity only (no confidentiality) requirements. > >>> > >>> In following the new IANA rules, we have posted the draft > >>> https://tools.ietf.org/html/draft-camwinget-tls-ts13- > macciphersuites-00 > >>> to document request for registrations of HMAC based cipher selections > >>> with TLS 1.3…..and are soliciting feedback from the WG on the draft > >>> and its path forward. > >> > >> As ekr pointed out, with the new registration rules, > >> there's nothing to stop someone defining any old set > >> of crypto stuff and getting non-recommended codepoints. > >> > >> That said, I don't consider that defining such > >> vulnerable-by-design ciphersuites is a good plan. > >> > >> - It imposes costs on the non-niche users of TLS - once > >> these things are defined then developers and those who > >> deploy/configure applications using TLS need to check > >> that they're not using these undesirable ciphersuites, > >> so costs are being displaced from niche uses to the > >> vast majority of implementations and deployments, which > >> seems to me to be a bad idea. And we know that people > >> will sometimes get those checks wrong leading to unexpected > >> transmission of plaintext over the Internet. > >> > >> - Similarly, just defining such ciphersuites seems likely > >> to lead to less well tested and infrequently used code > >> paths, which is undesirable. (Assuming someone pays some > >> developer to add these to some library, which generally > >> does seem to happen.) > >> > >> - RFC7525 [1] is clear on this topic (after debate in the > >> UTA WG) - "Implementations MUST NOT negotiate the cipher > >> suites with NULL encryption" and I see nothing new to > >> convince me that that ought change for TLS1.3. > >> > >> - Code footprint arguments aren't that convincing to > >> me - to get interop for the few devices where AES being > >> present or absent could make a real difference, you'd > >> need an awful lot more profiling of TLS or DTLS. I don't > >> see evidence of that so the interop/footprint arguments > >> seem pretty weak. I'd also bet that any useful "tiny > >> footprint" profile of that kind would end up targeting > >> loads of use-cases where confidentiality is absolutely > >> required. > >> > >> - (In addition to the good points made by Geoffrey > >> Keating [2]) cleartext payloads would also assist in > >> device fingerprinting, making it easier to exploit > >> vulnerabilities at scale. > >> > >> - IIUC there is also a desire to encrypt firmware > >> updates so that patches can be distributed more quickly > >> than attackers can reverse-engineer attacks. [4] I'm > >> not entirely sure if that's really likely to happen, > >> but if it were, then devices would need to be able to > >> use recommended ciphersuites in any case. > >> > >> - TLS/AX.25 doesn't seem that good a plan in any > >> case - according to [3], which seems reasonable to > >> me, using clear-signed GPG is quicker and better > >> meets the oddball regulations. Attempting to deal > >> with those regulations by weakening TLS seems like > >> a very bad plan, as you'd fail in any case to achieve > >> interop with normal TLS applications like the web. > >> (And the advertising is as illegal as the crypto > >> apparently, though I do like that aspect:-) > >> > >> - WRT unix sockets, I'm not clear that there's a > >> sufficiently important performance improvement in > >> real deployments to justify introducing weakened > >> ciphersuites - presumably mail servers are going to > >> use standard TLS libraries that (I hope!) won't be > >> offering NULL encryption, so I'd be surprised if > >> the right engineering decision was to prioritise > >> CPU to that extent, given the risks associated with > >> having weak ciphersuites present in widely used > >> implementations. IOW, it seems more sensible to me > >> for mail servers to just stick to using RECOMMENDED > >> ciphersuites. And given that you could use SASL > >> with Postfix/LMTP [5] I'm not sure why you'd want > >> a weirdo-version of TLS1.3 anyway but maybe there's > >> some reason I don't get. > >> > >> - I think this WG has had to spend waaaay too much > >> time dealing with the "inspection of data" debate in > >> various forms, but we did get an answer (no consensus) > >> in the end for that. Niche use cases seem extremely > >> unlikely to me to justify revisiting that painful > >> topic. > >> > >> So all in all, I just don't see a need for these > >> weak-by-design ciphersuites to even be defined. I'd > >> encourage folks who think they're needed to instead > >> think about how using RECOMMENDED ciphersuites might > >> make their implementations more widely applicable and > >> safer. Seems like a much more productive approach to > >> me anyway. > >> > >> Regards, > >> S. > >> > >> [1] https://tools.ietf.org/html/rfc7525 > >> [2] https://mailarchive.ietf.org/arch/msg/tls/ > uI8xVgp7gTuJgwUyY-UgZfmUkRo > >> [3] https://tools.ietf.org/html/draft-ietf-suit-architecture- > 01#section-3.3 > >> [4] https://www.tapr.org/pdf/DCC2010-AX.25- > AuthenticationEffects-KE5LKY.pdf > >> [5] http://www.postfix.org/SASL_README.html#client_sasl > >> > >> > >> <0x5AB2FAF17B172BEA.asc> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > >
- [TLS] integrity only ciphersuites Nancy Cam-Winget (ncamwing)
- Re: [TLS] integrity only ciphersuites Eric Rescorla
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Jack Visoky
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Eric Rescorla
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Ted Lemon
- Re: [TLS] integrity only ciphersuites Mike Bishop
- Re: [TLS] integrity only ciphersuites Nancy Cam-Winget (ncamwing)
- Re: [TLS] integrity only ciphersuites Judson Wilson
- Re: [TLS] integrity only ciphersuites Geoffrey Keating
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Lyndon Nerenberg
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Judson Wilson
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Peter Gutmann
- Re: [TLS] integrity only ciphersuites Stephen Farrell
- Re: [TLS] integrity only ciphersuites Viktor Dukhovni
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Judson Wilson
- Re: [TLS] integrity only ciphersuites Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] integrity only ciphersuites Viktor Dukhovni
- Re: [TLS] integrity only ciphersuites Kathleen Moriarty
- Re: [TLS] integrity only ciphersuites Stephen Farrell
- Re: [TLS] integrity only ciphersuites Bill Frantz
- Re: [TLS] integrity only ciphersuites Andreas Walz
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Jack Visoky
- Re: [TLS] integrity only ciphersuites Richard Barnes
- Re: [TLS] integrity only ciphersuites Stephen Farrell
- Re: [TLS] integrity only ciphersuites Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Ted Lemon
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Jack Visoky
- Re: [TLS] integrity only ciphersuites Fries, Steffen
- Re: [TLS] integrity only ciphersuites Salz, Rich
- Re: [TLS] integrity only ciphersuites Fries, Steffen
- Re: [TLS] integrity only ciphersuites Ted Lemon
- Re: [TLS] integrity only ciphersuites Salz, Rich
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Ted Lemon
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Stephen Farrell
- Re: [TLS] integrity only ciphersuites Fries, Steffen
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Jack Visoky
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Jack Visoky
- Re: [TLS] integrity only ciphersuites Salz, Rich
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Ted Lemon
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Jack Visoky
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Ted Lemon
- Re: [TLS] integrity only ciphersuites Bill Frantz
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Salz, Rich
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Jack Visoky
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Ted Lemon
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Jack Visoky
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Jack Visoky
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Viktor Dukhovni
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Eric Rescorla
- Re: [TLS] null auth ciphers for TLS 1.3? Viktor Dukhovni
- Re: [TLS] null auth ciphers for TLS 1.3? Eric Rescorla
- Re: [TLS] null auth ciphers for TLS 1.3? David Benjamin
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] integrity only ciphersuites Martin Thomson
- Re: [TLS] null auth ciphers for TLS 1.3? Peter Gutmann
- Re: [TLS] integrity only ciphersuites Peter Gutmann
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Peter Gutmann
- Re: [TLS] raw public keys in the wild? Viktor Dukhovni
- Re: [TLS] raw public keys in the wild? Peter Gutmann
- Re: [TLS] null auth ciphers for TLS 1.3? Wang Haiguang
- Re: [TLS] null auth ciphers for TLS 1.3? Bill Frantz
- Re: [TLS] EXTERNAL: Re: integrity only ciphersuit… Nancy Cam-Winget (ncamwing)
- Re: [TLS] integrity only ciphersuites Nancy Cam-Winget (ncamwing)
- Re: [TLS] raw public keys in the wild? Richard Barnes
- Re: [TLS] raw public keys in the wild? Viktor Dukhovni