Re: [TLS] stapling OCSP/CT for client cert?
On Wed, Feb 22, 2017 at 05:23:22PM +, David Benjamin wrote: > Looks like TLS 1.3 already allows this for CT, though not OCSP. Would take > all of four characters to fix. See this table: > https://tlswg.github.io/tls13-spec/#rfc.section.4.2 > > One of the nice things about using TLS-style extensions in > CertificateRequest is any ClientHello => (Server)Certificate extensions > naturally extend to CertificateRequest => (Client)Certificate extensions. That got me to review the message assignments of extensions. I found several problematic definitions: 1) Client_certificate_url (CH, EE): This is related to client certificate, but it also has more serious problem: It uses its own handshake type in way that is seemingly ill-defined in context of TLS 1.3. 2) User_mapping (CH, EE): This is pretty special in TLS 1.2, by being three-pass, instead of the usual two-pass. It also has its own message in TLS 1.2. How exactly is that supposed to work in TLS 1.3, is the SupplementalData really supposed to become the first message in client 2nd flight (that should be specified) or is the message supposed to be chucked inside certificate extension (which would need adding CT to message assignments for the extension). 3) Cert_type (CH, EE): This is related to either client or server certificate. However, cert_type is older extension that was superceded by client_certificate_type and server_certificate_type. Deprecate? 4) Client_certificate_type (CH, EE): This extension is about client certificates, which would logically imply assignment of CR, CT. This comes rather important if there ever will be certificate type that make sense to mix and match with X.509 certificates from client context. E.g. Subcertificates implemented as certificate type. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#875: Additional Derive-Secret Stage
On Thu, Feb 9, 2017 at 4:15 PM, Eric Rescorla wrote: > I've just posted a pull request which slightly adjusts the structure of > key derivation. > PR#875 adds another Derive-Secret stage to the left side of the key ladder > between each pair of HKDF-Extracts. There are two reasons for this: > > - Address a potential issue raised by Trevor Perrin where an attacker > somehow forces the IKM value to match the label value for Derive-Secret, > in which case the output of HKDF-Extract would match the derived secret. > This doesn't seem like it should be possible for any of the DH variants > we are using, and it's not clear that it would lead to any concrete > attack, but in the interest of cleanliness, it seemed good to address. > > - Restore Extract/Expand parity which gives us some flexibility in > case we want to replace HKDF. > I want to stress, also as advise for future uses of HKDF, that a recommended practice for HKDF is to always follow HKDF-extract with HKDF-expand. That's how HKDF is defined and departing from it should be done with utmost care. The issue raised by Trevor is an example of such subtleties. In particular, note that HKDF-Extract does not carry a "info" input while HKDF-Expand does, and such field is almost always essential for key separation and to tie derived keys to some particular context. Hugo > I don't expect this change to be controversial and I'll merge it on Monday > unless I hear objections. > > Thanks, > -Ekr > > > > > > > > ___ > 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
Re: [TLS] stapling OCSP/CT for client cert?
https://github.com/tlswg/tls13-spec/pull/880 I knew it was easy to fix, wasn’t sure if folks wanted it. Gives me a reason to join the contributors list. Very useful in peer-to-peer situations. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] stapling OCSP/CT for client cert?
Looks like TLS 1.3 already allows this for CT, though not OCSP. Would take all of four characters to fix. See this table: https://tlswg.github.io/tls13-spec/#rfc.section.4.2 One of the nice things about using TLS-style extensions in CertificateRequest is any ClientHello => (Server)Certificate extensions naturally extend to CertificateRequest => (Client)Certificate extensions. On Wed, Feb 22, 2017 at 12:13 PM Salz, Rich wrote: Any thoughts on being able to staple OCSP (or CT) data to a client cert once requested by the server? -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz ___ 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] stapling OCSP/CT for client cert?
Any thoughts on being able to staple OCSP (or CT) data to a client cert once requested by the server? -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
On Wed, Feb 22, 2017 at 08:04:13AM +, Salz, Rich wrote: > Why not just say > The CCM cipher suites are not (currently) defined for TLS 1.3 > > And leave it at that. We're all quite proud of the fact, and > deservedly so, that we only have three ciphers defined for TLS 1.3. > Let's try to hold that position as long as possible. Well, AES-128-CCM with 8 and 16 byte tags does exist in editor's copy (0x1304 and 0x1305). No AES-256-CCM tho. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
> On 22 Feb 2017, at 8:42, Martin Thomson wrote:
>
> On the interaction with TLS 1.3, we probably need a decision to be made:
>
> 1. strike TLS 1.3 from the document and only mention it in the way Joe
> suggests, TLS 1.3 doesn't get the CCM suites (it already has the
> equivalent of the GCM suites)
>
> 2. strike TLS 1.3 from the document, and add new TLS 1.3 CCM cipher
> suites to TLS 1.3 proper
Wait, what am I missing?
From appendix A.4 in TLS 1.3:
+--+-+
| Description | Value |
+--+-+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| | |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| | |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| | |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| | |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+--+-+
So, how do we not have CCM in TLS 1.3 given that things like ECDHE and PSK are
now orthogonal to ciphersuites?
Yoav___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
Why not just say The CCM cipher suites are not (currently) defined for TLS 1.3 And leave it at that. We're all quite proud of the fact, and deservedly so, that we only have three ciphers defined for TLS 1.3. Let's try to hold that position as long as possible. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
