Re: [TLS] [Editorial Errata Reported] RFC8446 (6127)

2020-05-01 Thread William Whyte
>From the perspective of someone who spends a lot of his time writing/editing >standards, I agree with the Errata and disagree with Peter's comment. If >"abort" and "terminate" mean the same thing, that should be made clear. Words >in standards need to have specific definitions. A developer who

Re: [TLS] [Editorial Errata Reported] RFC8446 (6120)

2020-05-01 Thread William Whyte
I think the point here is that the "transport" isn't a "data stream", the transport is what the data stream is delivered over. I agree that the intended meaning is clear, but the text as written isn't correct, and if the draft's being corrected anyway this should be corrected too. William

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

2018-08-24 Thread William Whyte
Hi all -- as editor of 1609.2 (and a contributor to 103 097) I'd like to recommend that the WG moves forward with consideration of this draft. There are a number of initiatives in the connected vehicle space that need TLS with 1609.2 certificates, and in particular ISO 21177, which is currently in

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

2018-08-27 Thread William Whyte
Hi Wang, The 1609.2 certificate format consists of both explicit and implicit certificates. The explicit certificates are in 1609.2 format, not in X.509 format. Cheers, William On Mon, Aug 27, 2018 at 4:43 AM, Wang Haiguang < wang.haiguang.shield...@huawei.com> wrote: > Hi, Mounira > > Thanks

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

2018-10-02 Thread William Whyte
Hi Ilari, >> - The construction looks like it mixes different kinds of structures: 1609.2 Data of type signed versus TLS 1.3 signature. I do not think this is cryptographically kosher. In fact, I think the call for "extreme care" for certain kinds of modifications from TLS 1.3 specificatio

Re: [TLS] kicking off charter revision discussion

2018-10-29 Thread William Whyte
I’m happy to submit the draft as it stands. I think it’s covered by the recharter below under “maintain” the spec, though perhaps we should suggest that this is changed to “maintain and, as necessary, extend”. Cheers, William On Oct 24, 2018, 8:20 PM -0400, Sean Turner , wrote: > With the final

[TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt

2015-09-20 Thread William Whyte
ed message -- From: Date: Sun, Sep 20, 2015 at 10:32 PM Subject: New Version Notification for draft-whyte-qsh-tls13-01.txt To: Zhenfei Zhang , William Whyte < wwh...@securityinnovation.com>, "John M. Schanck" < jscha...@securityinnovation.com> A new version of I-D,

Re: [TLS] bikeshed: Forward Security or Secrecy?

2015-12-01 Thread William Whyte
If we want to change to “key erasure” we should synch with CFRG and SAAG to ensure it’s used IETF-wide. I don’t think that “forward secrecy” is so broken that it needs fixing. Cheers, William *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Tony Arcieri *Sent:* Monday, November 30,

Re: [TLS] PR #604 Change "supported_groups" to "supported_kems"

2016-09-13 Thread William Whyte
I'd like to just check and see if there are any objections to this PR. There seems no reason to bake a particular cryptographic family into our terminology. This is a low-cost change that will save us from looking silly in a few years time. Cheers, William On Tue, Sep 13, 2016 at 1:19 PM, Sean T

Re: [TLS] draft-sullivan-tls-exported-authenticator-00

2016-11-01 Thread William Whyte
I'm confused by the line "These messages are not encrypted", because on a plain reading it could mean that the authenticator is sent outside the encrypted TLS session. That would be bad because it would mean that clients that wanted to authenticate themselves but to the server only wouldn't be able

Re: [TLS] draft-sullivan-tls-exported-authenticator-00

2016-11-01 Thread William Whyte
That makes sense, but it'd be good to clarify the text. Thanks! William -- sent from my phone On Nov 1, 2016 11:57 AM, "Ilari Liusvaara" wrote: > On Tue, Nov 01, 2016 at 04:41:44AM -0400, William Whyte wrote: > > I'm confused by the line "These message

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

2017-02-24 Thread William Whyte
Right. I fee l strongly that it'd be wise to bless a single 256-bit cipher as part of the core TLS 1.3 family of techniques, but I don't feel strongly that it should be AES-256. ChaCha? Cheers, William On Fri, Feb 24, 2017 at 9:55 AM, Salz, Rich wrote: > > There's an argument that it's worth b

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

2017-02-24 Thread William Whyte
There's an argument that it's worth building in a 256-bit cipher for quantum resistance. Not clear that AES-256 is the best 256-bit cipher though. William On Fri, Feb 24, 2017 at 9:07 AM, Salz, Rich wrote: > > Assuming 256-bit AES-CCM suites are needed, I think the better place to > put > > the

Re: [TLS] AdditionalKeyShare Internet-Draft

2017-04-20 Thread William Whyte
Link to that draft: https://tools.ietf.org/html/draft-whyte-qsh-tls13-02 Cheers, William On Wed, Apr 19, 2017 at 2:42 PM, Scott Fluhrer (sfluhrer) < sfluh...@cisco.com> wrote: > > > -Original Message- > > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Douglas Stebila > > Sent: Mon

Re: [TLS] AdditionalKeyShare Internet-Draft

2017-04-20 Thread William Whyte
Sorry! Link to the most recent version... https://tools.ietf.org/html/ draft-whyte-qsh-tls13-04 William On Thu, Apr 20, 2017 at 1:08 PM, William Whyte wrote: > Link to that draft: https://tools.ietf.org/html/draft-whyte-qsh-tls13-02 > > Cheers, > > William > > On Wed, Ap