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

From: Hubert Kario <[email-masked]>
Date: Fri, 02 Sep 2016 19:31:52 +0200

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

---

From: David Benjamin <[email-masked]>
Date: Fri, 02 Sep 2016 19:21:10 +0000

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 <[email-masked]> wrote:

> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech
> Republic_______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Sep 2016 12:23:03 -0700

I agree. FWIW, this is how NSS behaves. A clarifying PR would be welcome
here.

On Fri, Sep 2, 2016 at 12:21 PM, David Benjamin <[email-masked]>
wrote:

> 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
> _______________________________________________
> TLS mailing list
> [email-masked]

---

From: Hubert Kario <[email-masked]>
Date: Fri, 02 Sep 2016 21:35:39 +0200

> I agree. FWIW, this is how NSS behaves. A clarifying PR would be welcome

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.