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 SHA256 (for TLS 1.2),
regardl
> 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
https://www.ietf.org/mailman/l
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 chains of course use SHA256.
>
I am too lazy to chec
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 =
HMAC(fini
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 included in the
> calcu
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 4.4.4 defines the v
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 have expected to see it included i
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 has
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 use SHA256.
Actually, lookin
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
>
> I agree with David here. Specifically, I think.
>
> - The base specification should continue to forbid certificates in
> combination with PSK
> - We should at some point contemplate an extension that allows the use of
> certificates in combination with PSK
> - The base spec should be factored
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 chains of course use SHA256.
>
> Sorry I meant to say
Ryan Sleevi wrote:
>
> I would say that the vast majority of servers deployed on the Internet
> using commonly publicly trusted CAs have more than one chain to choose from
> - often dependent on the installed trust anchors - but the servers may
> simply not be aware of it, and relying on clients t
Why would the external PSK not just go into he PSK slot.
-Ekr
On Fri, Mar 24, 2017 at 9:16 AM, Russ Housley wrote:
>
> > I agree with David here. Specifically, I think.
> >
> > - The base specification should continue to forbid certificates in
> combination with PSK
> > - We should at some poi
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 hand was the ques
On 3/24/2017 11:44 AM, 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: CN=cloudflare.com, ...
contai
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
Fi
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 following in Section 4.4.4:
>
> *Onc
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: CN=cloudflare.com
On Fri, Mar 24, 2017 at 12:30 PM, Michael StJohns
wrote:
> On 3/24/2017 11:44 AM, 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
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 [mai
21 matches
Mail list logo
