On Wed, Mar 9, 2016 at 6:05 AM, Hannes Tschofenig
wrote:
> I still hope that this can be taken into consideration. I saw the
> proposal from Martin about defining another extension. This may be an
> option and maybe the answer is as simple as "don't use certificates for
> such scenarios".
I'm not
Based on your explanation, the best solution architecture would be based
on *attribute* certificates (individual attributes signed independently by
their corresponding Attribute Authorities), rather than the current
“all-crammed-in” certificates.
The downside of the above is that this approach isn
Hi Adam,
as Thomas mentioned in his email we are looking into extending the SNI
functionality.
Let me explain why we are doing it.
We are focused on Internet of Things deployments and we want to use
TLS/DTLS there to provide communication security. The use of TLS/DTLS
would solve some of the pro
On 7 March 2016 at 12:32, Martin Thomson wrote:
> On 7 March 2016 at 23:02, Hubert Kario wrote:
> > well, if some people don't care about their implementation being
> > fingerprintable, let them be, but there should but at least a
> > recommendation what to do if you want to avoid that.
>
> I'd
On Monday 07 March 2016 23:32:55 Martin Thomson wrote:
> On 7 March 2016 at 23:02, Hubert Kario wrote:
> > well, if some people don't care about their implementation being
> > fingerprintable, let them be, but there should but at least a
> > recommendation what to do if you want to avoid that.
>
On 7 March 2016 at 23:02, Hubert Kario wrote:
> well, if some people don't care about their implementation being
> fingerprintable, let them be, but there should but at least a
> recommendation what to do if you want to avoid that.
I'd be very surprised if this added anything to the fingerprintin
On Friday 04 March 2016 10:16:25 Martin Thomson wrote:
> If we actually have a volunteer for sni-bis, then that would be OK
> with me.
>
> However, I don't regard the errors as important. Any hope that they
> might be used in some automated fashion died a long time ago. Mainly
> due to this comp
On Thursday 03 March 2016 20:43:42 Dave Garrett wrote:
> Do we want to stick some simple new constraints on SNI in the TLS 1.3
> draft spec? e.g. SHOULD have exactly one host_name which SHOULD be
> less than N bytes (significantly less than the current theoretical
> 64kB ceiling). Just adding a qui
On 3 March 2016 at 23:16, Martin Thomson wrote
:
>
> I assume that the last
> error indicates that you didn't get an alert, which I find is
> alarmingly common in TLS.
>
>
Yes, that's right.
Cheers
Rich.
___
TLS mailing list
TLS@ietf.org
https://ww
On 04/03/2016 07:58, "EXT Yuhong Bao" wrote:
>
>> From: thomas.foss...@nokia.com
>> To: a...@imperialviolet.org; tls@ietf.org
>> Date: Fri, 4 Mar 2016 07:10:06 +
>> Subject: Re: [TLS] Accepting that other SNI nam
On 04/03/2016 08:42, "TLS on behalf of Martin Thomson"
wrote:
>On 4 March 2016 at 18:10, Fossati, Thomas (Nokia - GB)
> wrote:
>> In CoRE we might need to allocate a new SNI NameType for non-DNS host
>> names [1].
>>
>> Removing SNI extensibility would make it unfeasible.
>
>Not at all.
It would
On 4 March 2016 at 18:10, Fossati, Thomas (Nokia - GB)
wrote:
> In CoRE we might need to allocate a new SNI NameType for non-DNS host
> names [1].
>
> Removing SNI extensibility would make it unfeasible.
Not at all. Define a new extension. We have evidence that that works.
Trying again...
> Hi Adam,
In CoRE we might need to allocate a new SNI NameType for non-DNS host
names [1].
Removing SNI extensibility would make it unfeasible.
Cheers, t
[1]
https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-00#section
-3.3
>On 03/03/2016 18:49, "TLS on beha
Hi Adam,
On 03/03/2016 18:49, "TLS on behalf of Adam Langley" wrote:
>The Server Name Indication (SNI) extension in TLS has a provision to
>provide names other than host names[1]. None have even been defined to
>my knowledge, but it's there.
>
>OpenSSL (and possibly others) have had a long-stand
On 4 March 2016 at 12:43, Dave Garrett wrote:
> Just adding a quick blurb for this in there somewhere seems like the simplest
> solution to me.
That doesn't fix it for 1.2, but I'd be OK with that. Define SNI as:
struct {
uint16 extension_tag = 0;
uint16 extension_length = strlen(name) +
Do we want to stick some simple new constraints on SNI in the TLS 1.3 draft
spec? e.g. SHOULD have exactly one host_name which SHOULD be less than N bytes
(significantly less than the current theoretical 64kB ceiling). Just adding a
quick blurb for this in there somewhere seems like the simplest
If we actually have a volunteer for sni-bis, then that would be OK with me.
However, I don't regard the errors as important. Any hope that they
might be used in some automated fashion died a long time ago. Mainly
due to this complete lack of consistency. I assume that the last
error indicates t
If you're fixing that then maybe standardising the errors makes sense too.
My fingerprinter sees the following:
For an empty name:
SNIEmptyName: *(301)alert:DecodeError:fatal|
SNIEmptyName: *(301)alert:HandshakeFailure:fatal|
SNIEmptyName: *(301)alert:IllegalParameter:fatal|
SNIEmptyName: *(303)a
On 4 March 2016 at 05:49, Adam Langley wrote:
> (I think the lesson here is that protocols should have a single joint,
> and that it should be kept well oiled. For TLS, that means that
> extensions should have minimal extensionality in themselves and that
> we should generally rely on the main ext
I’m in favor, wearing both OpenSSL and Akamai hats.
And wouldn’t it be a much kinder world if Adam wrote all posts on this list? ☺
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
TLS mailing list
TLS@ietf.org
https
On Thu, Mar 3, 2016 at 10:56 AM, Eric Rescorla wrote:
> Note: it's already the case that it's forbidden to send >1 of any given type
> of name. NSS does not presently enforce this rule but will do so soon.
(We have enforced that for a while without issues.)
Cheers
AGL
--
Adam Langley a...@im
On Thu, Mar 3, 2016 at 10:49 AM, Adam Langley
wrote:
> The Server Name Indication (SNI) extension in TLS has a provision to
> provide names other than host names[1]. None have even been defined to
> my knowledge, but it's there.
>
> OpenSSL (and possibly others) have had a long-standing bug[2] (f
The Server Name Indication (SNI) extension in TLS has a provision to
provide names other than host names[1]. None have even been defined to
my knowledge, but it's there.
OpenSSL (and possibly others) have had a long-standing bug[2] (fixed
in master) that means that different types of names will ca
23 matches
Mail list logo
