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
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 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
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
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
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
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
>
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
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
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
> 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
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
> 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 multiple digest algorithms for otherwise
identical chains (same public key a
On 24 March 2017 at 12:29, Viktor Dukhovni wrote:
> I've never seen
> a TLS server that has multiple chains to choose from for the same
> server identity.
I didn't have to look far. www.cloudflare.com will switch hit and
pick RSA or ECDSA on demand:
$ ./tstclnt -h www.cloudflare.com -p 443 -D -
> On Mar 23, 2017, at 9:00 PM, Peter Gutmann wrote:
>
> See several previous discussions on the rationale behind
> this (hmm, if you can find them :-).
See, for example, the thread that contains:
https://www.ietf.org/mail-archive/web/tls/current/msg17977.html
I chose that message because it
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),
regardless of what the other side advertises. There was a
Fries, Steffen writes:
>I looked through the mailing list but did not find an immediate answer to my
>question, but I guess, it must have been discussed already.
It's been discussed several times, but I'm not sure which search terms you'd
have to apply to find the threads... the general consens
On Thu, Mar 23, 2017 at 10:24 AM, Martin Rex wrote:
> Eric Rescorla wrote:
> >>
> >> based on your reply my conclusion is that
> >>
> >> - there is no (standard compliant) way for a server to use a
> >> SHA256 based certificate for server side authentication in cases where
> the
> >> cli
a
> *Sent:* Thursday, March 23, 2017 9:58 AM
> *To:* Fries, Steffen
> *Cc:* TLS WG
> *Subject:* Re: [TLS] Enforcing stronger server side signature/hash
> combinations in TLS 1.2
>
>
>
>
>
>
>
> On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen
> wrote:
>
&
Eric Rescorla wrote:
>>
>> based on your reply my conclusion is that
>>
>> - there is no (standard compliant) way for a server to use a
>> SHA256 based certificate for server side authentication in cases where the
>> client does not provide the signature_algorithm extension
>
> Not quite.
lf Of Eric Rescorla
Sent: Thursday, March 23, 2017 9:58 AM
To: Fries, Steffen
Cc: TLS WG
Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations
in TLS 1.2
On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen
mailto:steffen.fr...@siemens.com>> wrote:
Hi Erik,
based
On Thu, Mar 23, 2017 at 9:44 AM, Martin Rex wrote:
> Fries, Steffen wrote:
> >
> > based on your reply my conclusion is that
> >
> > - there is no (standard compliant) way for a server to use a SHA256
> > based certificate for server side authentication in cases where the
> > client does not pro
On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen
wrote:
> Hi Erik,
>
>
>
> based on your reply my conclusion is that
>
> - there is no (standard compliant) way for a server to use a
> SHA256 based certificate for server side authentication in cases where the
> client does not provide the
: Thursday, March 23, 2017 8:37 AM
To: TLS WG
Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations
in TLS 1.2
Hi Erik,
based on your reply my conclusion is that
- there is no (standard compliant) way for a server to use a SHA256
based certificate for server side
Fries, Steffen wrote:
>
> based on your reply my conclusion is that
>
> - there is no (standard compliant) way for a server to use a SHA256
> based certificate for server side authentication in cases where the
> client does not provide the signature_algorithm extension
The statement quoted by E
Hi Erik,
based on your reply my conclusion is that
- there is no (standard compliant) way for a server to use a SHA256
based certificate for server side authentication in cases where the client does
not provide the signature_algorithm extension
- clients should always use the
Hi Viktor,
thanks for the response, I replied inline.
> According to TLS 1.2 section 7.4.1.4.1. a client may use the
> signature_algorithm extension to signal any combinations the client
> supports, listed in the order of preferences.
The signature algorithm is primarily about signatures made
On Thu, Mar 23, 2017 at 7:39 AM, Viktor Dukhovni
wrote:
>
> > On Mar 23, 2017, at 10:31 AM, Fries, Steffen
> wrote:
> >
> > According to TLS 1.2 section 7.4.1.4.1. a client may use the
> > signature_algorithm extension to signal any combinations the
> > client supports, listed in the order of p
> On Mar 23, 2017, at 10:31 AM, Fries, Steffen
> wrote:
>
> According to TLS 1.2 section 7.4.1.4.1. a client may use the
> signature_algorithm extension to signal any combinations the
> client supports, listed in the order of preferences.
The signature algorithm is primarily about signatures
29 matches
Mail list logo
