Martin Thomson writes:
>The opposite in fact. NSS checks extensions first. That is how we filter out
>ECC cipher suites if the named_groups extension doesn't list anything we
>support.
I have to do the same thing, bouncing back and forth between cipher suites and
extensions in order to find so
Martin Thomson writes:
>An endpoint that receives an illegal combination of "things" MAY choose to
>treat that as a fatal error.
Does that actually help? What it's saying in full is:
An endpoint that receives an illegal combination of "things" MAY choose to
treat that as a fatal error or
PR to put this into writing:
https://github.com/tlswg/tls13-spec/pull/232
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
> An endpoint that receives an illegal combination of "things" MAY choose to
> treat that as a fatal error.
>From the guy who wrote that Postel was wrong.
But +1 from me.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Thu, Aug 27, 2015 at 1:06 PM, Martin Thomson
wrote:
> The statement I'd like to see is something like this...
>
> An endpoint that receives an illegal combination of "things" MAY choose to
> treat that as a fatal error.
>
This seems totally reasonable.
-Ekr
> In this case, that means that i
On Thu, Aug 27, 2015 at 1:01 PM, Martin Thomson
wrote:
> The opposite in fact. NSS checks extensions first. That is how we filter
> out ECC cipher suites if the named_groups extension doesn't list anything
> we support.
>
Well, yes and no. We don't for instance check for the *absence* of the
ext
The statement I'd like to see is something like this...
An endpoint that receives an illegal combination of "things" MAY choose to
treat that as a fatal error.
In this case, that means that if you include an ECDHE suite without an
ECDHE named_group, don't expect to have the connection succeed.
On
On Thu, Aug 27, 2015 at 12:26:03PM -0700, Eric Rescorla wrote:
> My problem is precisely the conflation of offering with negotiating. The
> way that many stacks work (for instance NSS) is that they negotiate the
> cipher suite *first* and then they check for the presence or absence of
> the releva
The opposite in fact. NSS checks extensions first. That is how we filter
out ECC cipher suites if the named_groups extension doesn't list anything
we support.
On Aug 27, 2015 12:26 PM, "Eric Rescorla" wrote:
>
>
> On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett
> wrote:
>
>> On Thursday, August 2
On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote:
> My problem is precisely the conflation of offering with negotiating. The way
> that
> many stacks work (for instance NSS) is that they negotiate the cipher suite
> *first* and then they check for the presence or absence of the relevan
On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett
wrote:
> On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote:
> > I've been looking at the latest TLS 1.3 spec and there are a lot of
> > MUSTs that are completely toothless. To pick on a recent changeset:
> >
> > > The signature algorithm
On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote:
> I've been looking at the latest TLS 1.3 spec and there are a lot of
> MUSTs that are completely toothless. To pick on a recent changeset:
>
> > The signature algorithm and hash algorithm MUST be a pair offered in the
> "signature_al
On Thu, Aug 27, 2015 at 11:48 AM, Martin Thomson
wrote:
> I've been looking at the latest TLS 1.3 spec and there are a lot of
> MUSTs that are completely toothless. To pick on a recent changeset:
>
> > The signature algorithm and hash algorithm MUST be a pair offered in the
> "signature_algorith
I've been looking at the latest TLS 1.3 spec and there are a lot of
MUSTs that are completely toothless. To pick on a recent changeset:
> The signature algorithm and hash algorithm MUST be a pair offered in the
"signature_algorithms" extension (see {{signature-algorithms}}).
> All implementation
On Thu, Aug 27, 2015 at 01:22:33PM -0400, Santosh Chokhani wrote:
> To me it seems that both of these wordings could be interpreted by someone
> that if you do not have a trust anchor and you get it in the TLS handshake,
> you can use it and trust it.
>
> That sounds dangerous.
Beyond a general
To me it seems that both of these wordings could be interpreted by someone
that if you do not have a trust anchor and you get it in the TLS handshake,
you can use it and trust it.
That sounds dangerous.
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett
S
On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide <
viktor.s.wold.e...@gmail.com> wrote:
> On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote:
>
>>
>>
>> TLS 1.3 encrypts both the client's and server's certificates already.
>> The server's certificate is secure only against passive attack.
On Thu, Aug 27, 2015 at 1:37 AM, Viktor S. Wold Eide <
viktor.s.wold.e...@gmail.com> wrote:
>
> On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote:
>
>>
>>
>> On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide <
>> viktor.s.wold.e...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I am looking for a wa
On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote:
>
>
> TLS 1.3 encrypts both the client's and server's certificates already.
> The server's certificate is secure only against passive attack. The
> client's is encrypted with a key that the client can authenticate as
> belonging to the server
On Tue, Aug 25, 2015 at 10:43 AM, Pascal Urien
wrote:
> Hi
>
> a working solution fot TLS 1.0,1.1, 1.2, DTLS 1.0, 1.2 is to encrypt
> the client certificat with an extra key computed from the master
> secret
>
> see
>
> https://tools.ietf.org/html/draft-urien-badra-eap-tls-identity-protection-01
On Tue, Aug 25, 2015 at 12:19 AM, Badra wrote:
> Hi,
>
> Another solution was approved for publication as experimental by IESG in
> 2009 but I declined to process with Pasi Eronen way (previous WG co-Chair)
> of publishing the document.
>
> It is available at
> https://tools.ietf.org/html/draft-h
On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote:
>
>
> On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide <
> viktor.s.wold.e...@gmail.com> wrote:
>
>> Hi,
>>
>> I am looking for a way to achieve identity hiding for DTLS 1.2, which
>> also hopefully can be used in (D)TLS 1.3, when availab
22 matches
Mail list logo
