Re: [TLS] handling of duplication of extensions between ServerHello and EncryptedExtensions

[Hubert Kario <[e-mail]>]

On Friday, 2 September 2016 12:23:03 CEST Eric Rescorla wrote:
> I agree. FWIW, this is how NSS behaves. A clarifying PR would be welcome
> here.

that was an easy one: https://github.com/tlswg/tls13-spec/pull/622

since there's already text prohibiting that situation:

  The ServerHello MUST only include extensions which are               
  required to establish the cryptographic context. Currently the only           
  such extensions are "key_share", "pre_shared_key", and "early_data".          
  Clients MUST check the ServerHello for the presence of any forbidden          
  extensions and if any are found MUST terminate the handshake with a           
  "illegal_parameter" alert.

and

   Extensions which are designated to               
   appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients              
   MUST check EncryptedExtensions for the presence of any forbidden                
   extensions and if any are found MUST terminate the handshake with an            
   "illegal_parameter" alert.
 
> On Fri, Sep 2, 2016 at 12:21 PM, David Benjamin <[e-mail]>
> 
> wrote:
> > Huh. I agree that text is weird. We should probably remove it. I think we
> > actually get something akin to what you suggest basically implicitly:
> > 
> > Servers aren't allowed to send unsolicited extensions, so your SH and EE
> > parsers should be rejecting any unknown extensions. If you combine that
> > with not accepting known extensions in the wrong context (unencrypted ALPN
> > or encrypted key_share) since extensions already specify which messages
> > they may live in, this all works out.
> > 
> > So even if we explicitly say this rule, I don't think reflecting it in
> > code is the cleanest implementation strategy. (It requires one keep a list
> > of SH extensions and compare against it.) It might be better to say that
> > extensions in unexpected contexts should be rejected like any other
> > unexpected extension.
> > 
> > David
> > 
> > On Fri, Sep 2, 2016 at 1:31 PM Hubert Kario <[e-mail]> wrote:
> >> So, the draft has following text:
> >>     The same extension types MUST NOT appear in both the ServerHello and
> >>     EncryptedExtensions.  If the same extension appears in both
> >>     locations,
> >>     the client MUST rely only on the value in the EncryptedExtensions
> >>     block.
> >> 
> >> if the extension "MUST NOT" be in both ServerHello and
> >> EncryptedExtensions,
> >> why the client should continue with the handshake if a server makes such
> >> a
> >> major mistake? Why aborting the connection in such situation isn't safer?
> >> --
> >> Regards,
> >> Hubert Kario
> >> Senior Quality Engineer, QE BaseOS Security team
> >> Web: www.cz.redhat.com
> >> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech
> >> Republic_______________________________________________
> >> TLS mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tls
> > 
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic