[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Accepting that other SNI name types will never work.
From:       Adam Langley <agl () imperialviolet ! org>
Date:       2016-03-09 15:58:39
Message-ID: CAMfhd9XvPUeypUQho+e6LA1iROvZaA-chVGSh2q6zFpLpbXRQQ () mail ! gmail ! com
[Download RAW message or body]

On Wed, Mar 9, 2016 at 6:05 AM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> 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 sure that I understand your use-case enough to say anything
intelligent about it I'm afraid.

I'm just noting here that adding new SNI types is pretty bug-rusted.
Now, if you have a completely separate ecosystem you can solve the
deployment issues, of course. But I worry that if new SNI types are
added then, sooner or later, people will start to run into problems
with the current implementation ecosystem and a bunch of effort will
be wasted which could have been avoided by defining a new extension.
Therefore I recommend defining a new extension rather than a new SNI
type. Additionally, I'm suggesting that, in general, it's a good idea
to avoid nesting extension-like structures inside an extension in
favour of adding top-level extensions as needed.


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org


[prev in list] [next in list] [prev in thread] [next in thread]