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
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 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 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 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 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.
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 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
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 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
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 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 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
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 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 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 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
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
> 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
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
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
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
22 matches
Mail list logo
