Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

EKR – I think that is the wrong answer because of the resume case. However, I would expect that the external PSK would be appended or otherwise munge into the computed secret (assuming DH) and would be consumed as part of that processing. No additional slot needed. jim From: TLS

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Michael StJohns wrote: > Martin Rex wrote: >> oops, typo: >> >> Martin Rex wrote: >>> Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com >>> I'm a little confused. >>> >>> This is the cert chain (as visualized by Microsoft CryptoAPI): >>> >>>server-cert:

Re: [TLS] Application Data before Client Finished message

On Fri, Mar 24, 2017 at 1:47 PM, Roelof Du Toit wrote: > I was wondering if Section 4.4.4 requires an additional exception to allow > sending Application Data from the server prior to receiving the client's > Finished message? > > > > The current draft has the

[TLS] Application Data before Client Finished message

I was wondering if Section 4.4.4 requires an additional exception to allow sending Application Data from the server prior to receiving the client's Finished message? The current draft has the following in Section 4.4.4: Once a side has sent its Finished message and received and validated the

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

On Fri, Mar 24, 2017 at 1:10 PM, Martin Rex wrote: > If Chrome really does AIA-fetching (*shudder*), how can it be disabled? > I can understand and appreciate your viewpoint, although we disagree. I'll save the rest of the list from rehashing that discussion, since the topic at

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

On Fri, Mar 24, 2017 at 1:23 AM, Viktor Dukhovni wrote: > > > On Mar 24, 2017, at 1:08 AM, Martin Thomson > wrote: > > > >> I've never seen > >> a TLS server that has multiple chains to choose from for the same > >> server identity. > > Both

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

oops, typo: Martin Rex wrote: > > Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com > I'm a little confused. > > This is the cert chain (as visualized by Microsoft CryptoAPI): > > server-cert: CN=cloudflare.com, ... > contains ECDSA P-256 public key >

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Viktor Dukhovni wrote: > > > On Mar 24, 2017, at 1:08 AM, Martin Thomson > > wrote: > > > >> I've never seen > >> a TLS server that has multiple chains to choose from for the same > >> server identity. > [ https://www.cloudflare.com/ ] > > Both chains of course

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Viktor Dukhovni wrote: > > The net effect is that in practice you simply ignore the signature > algorithms when it comes to the certificate chain. Essentially correct. This is the only reasonable, highly backwards compatible and perfectly secure choice. > > I've never seen a TLS server that

Re: [TLS] ClientFinished calculation following EndOfEarlyData in draft-19

https://github.com/tlswg/tls13-spec/pull/912 On Fri, Mar 24, 2017 at 6:32 AM, Eric Rescorla wrote: > > > On Fri, Mar 24, 2017 at 6:27 AM, Matt Caswell wrote: > >> In draft-19 EndOfEarlyData was changed from an alert to a handshake >> message. Therefore I would

Re: [TLS] ClientFinished calculation following EndOfEarlyData in draft-19

On Fri, Mar 24, 2017 at 6:27 AM, Matt Caswell wrote: > In draft-19 EndOfEarlyData was changed from an alert to a handshake > message. Therefore I would have expected to see it included in the > calculation of the ClientFinished (where early data is accepted). > However section

Re: [TLS] ClientFinished calculation following EndOfEarlyData in draft-19

I think it's a typo. My understanding is EndOfEarlyData was meant to be in the transcript. David On Fri, Mar 24, 2017 at 9:27 AM Matt Caswell wrote: > In draft-19 EndOfEarlyData was changed from an alert to a handshake > message. Therefore I would have expected to see it

[TLS] ClientFinished calculation following EndOfEarlyData in draft-19

In draft-19 EndOfEarlyData was changed from an alert to a handshake message. Therefore I would have expected to see it included in the calculation of the ClientFinished (where early data is accepted). However section 4.4.4 defines the verify_data as follows: verify_data =

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

On Thu, Mar 23, 2017 at 10:23 PM, Viktor Dukhovni wrote: > > > On Mar 24, 2017, at 1:08 AM, Martin Thomson > wrote: > > > >> I've never seen > >> a TLS server that has multiple chains to choose from for the same > >> server identity. > > Both

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

> Sorry I meant to say multiple digest algorithms for otherwise identical chains > (same public key algorithm and server name). We used to have to do this, during the MD5-deprecation days. ___ TLS mailing list TLS@ietf.org

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Peter Gutmann [pgut...@cs.auckland.ac.nz] writes Andrei Popov writes: >Unfortunately, in practice there are TLS 1.2 clients that support >SHA256, but don't advertise it via the signature algorithms extension. It's actually pretty safe to just automatically assume