Re: [Secdispatch] Agenda time request: DANE for IOT security

[Martin Thomson <[e-mail]>]

Please DON'T design for extensibility. That is another aspect of the SNI design you don't want. If this fails, get a new extension point.

On Sun, Nov 15, 2020, at 14:41, Shumon Huque wrote:
> On Sat, Nov 14, 2020 at 8:28 PM Eric Rescorla <[e-mail]> wrote:
> > I have reviewed these drafts. While I don't have any strong opinions about 
> > whether this technology is a good thing or not. I do have some thoughts about
> > the TLS binding.
> 
> Thanks for the review!
> 
> > 
> > Overall, it's probably not good to try to do the same thing for TLS
> > 1.3 and TLS 1.2, given the very different properties of client
> > authentication in the two protocols.
> > 
> > In 1.3 the right way to do this is for the server to indicate
> > willingness/desire for DANE information in the CertificateRequest and
> > the client to answer that in the Certificate. This will automatically
> > encrypt the contents of the extension without resort to ECH, just
> > as the client's cert is already encrypted.
> > 
> > TLS 1.2 doesn't support ECH nor does it it encrypt the certificate,
> > so it seems like ideally we would not support TLS 1.2 at all for
> > this extension. Is there a strong need for it?
> 
> Yeah, we're aware the privacy protections can only be achieved
> with TLS 1.3.
> 
> My assumption (possibly mistaken) has been that we will need
> to support deployed bases of both TLS 1.2 and 1.3.
> 
> However, since this protocol requires code changes in TLS stacks
> anyway, perhaps we can mandate TLS 1.3 only, and modify the
> protocol according to your suggestion (adding the new protocol
> elements to CertificateRequest and Certificate and remove the
> need for ECH).
> 
> I'll ponder and chat with some of the potential consumers of this
> technology re: TLS 1.2/1.3.
> 
>  
> > 
> > 
> > Your encoding for the extension is not extensible because it does
> > not contain a length as well as a type. 
> > 
> >    struct {
> >        NameType name_type;
> >        select (name_type) {
> >            case host_name: HostName;
> >        } name;
> >    } ClientName;
> > 
> >    ..
> >    
> >    struct {
> >        ClientName client_name_list<1..2^16-1>
> >    } ClientNameList;
> > 
> > The issue is that a receiver of an unknown type cannot properly skip
> > past it because it doesn't know the length (note that this is a known
> > problem in SNI as well). The correct approach is to have the ClientName
> > include a length field:
> > 
> >    struct {
> >        NameType name_type;
> >        uint16 length;               // NEW
> >        select (name_type) {
> >            case host_name: HostName;
> >        } name;
> >    } ClientName;
> > 
> >    struct {
> >        ClientName client_name_list<1..2^16-1>
> >    } ClientNameList;
> > 
> > Note that this will create a redundant length but that's basically
> > just the natural thing for TLS encoding and not really worth
> > fixing.
> 
> Thanks for this suggestion.
> 
> It was modelled after SNI, and thus inherited that defect :)
> 
> At the moment, only one name type (and one instance of it)
> is supported, so it doesn't really matter. But it is best to design
> for extensibility, so I will plan to add the additional length field.
> 
> Shumon.
> 
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>