Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Eric Rescorla]

On Fri, Mar 31, 2017 at 9:12 AM, Dr Stephen Henson <
li...@drh-consultancy.co.uk> wrote:

> On 27/03/2017 08:47, Olivier Levillain wrote:
> >
> > For a longer version, post-handshake records of type Handshake can be of
> > three kinds:
> > - NewSessionTicket (sent by the server, and that can safely be ignored
> > entirely by clients)
> > - KeyUpdate (sent by either party, requiring only a bit of state)
> > - CertificateRequest (sent by the server, an arbirary number of times,
> > and requring the client to keep some state *for each request*)
> >
> > Of course, this last item makes the post-handshake client state machine
> > explode, whereas the first two items can ben implemented in a trivial
> > way. The client can not indeed ignore all this state to answer, since it
> > is supposed to answer at least with a Finished message, which will cover
> > the CertificateRequest message. Moreover, since each of these Finished
> > messages must cover the initial handshake and the current
> > CertificateRequest message, it requires a forkable hash implementation,
> > which requires more memory.
> >
>
> To me allowing the server to send multiple certificate request messages
> and the
> client being permitted to respond to them in arbitrary order adds quite a
> bit of
> complexity.
>
> Is there a usage scenario for this? Would permitting only one outstanding
> Certificate Request be too limiting?
>

Yeah, with H2 it puts a lot of complexity at the HTTP layer. I think we
already
had consensus to allow this.



On a related note in 4.6.2:
>
>Note: Because client authentication may require prompting the user,
>servers MUST be prepared for some delay, including receiving an
>arbitrary number of other messages between sending the
>CertificateRequest and receiving a response.
>
> I'm assuming that once the client has responded with a Certificate message
> it
> MUST send CertificateVerify and Finished afterwards and nothing else is
> permissible? That is it can't send application data or respond to other
> outstanding CertificateRequest messages?
>

I think that was our intention but I agree the text ended up a bit unclear.
Absent some
argument, i'll update the text to require it.

-Ekr


>
> Steve.
> --
> Dr Stephen N. Henson.
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Freelance consultant see: http://www.drh-consultancy.co.uk/
> Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Dr Stephen Henson]

On 27/03/2017 08:47, Olivier Levillain wrote:
> 
> For a longer version, post-handshake records of type Handshake can be of
> three kinds:
> - NewSessionTicket (sent by the server, and that can safely be ignored
> entirely by clients)
> - KeyUpdate (sent by either party, requiring only a bit of state)
> - CertificateRequest (sent by the server, an arbirary number of times,
> and requring the client to keep some state *for each request*)
> 
> Of course, this last item makes the post-handshake client state machine
> explode, whereas the first two items can ben implemented in a trivial
> way. The client can not indeed ignore all this state to answer, since it
> is supposed to answer at least with a Finished message, which will cover
> the CertificateRequest message. Moreover, since each of these Finished
> messages must cover the initial handshake and the current
> CertificateRequest message, it requires a forkable hash implementation,
> which requires more memory.
> 

To me allowing the server to send multiple certificate request messages and the
client being permitted to respond to them in arbitrary order adds quite a bit of
complexity.

Is there a usage scenario for this? Would permitting only one outstanding
Certificate Request be too limiting?

On a related note in 4.6.2:

   Note: Because client authentication may require prompting the user,
   servers MUST be prepared for some delay, including receiving an
   arbitrary number of other messages between sending the
   CertificateRequest and receiving a response.

I'm assuming that once the client has responded with a Certificate message it
MUST send CertificateVerify and Finished afterwards and nothing else is
permissible? That is it can't send application data or respond to other
outstanding CertificateRequest messages?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Hubert Kario]

On Tuesday, 28 March 2017 08:23:33 CEST Kaduk, Ben wrote:
> On 3/13/17, 12:30, "Sean Turner"  wrote:
> Do we want to add some commentary about the extant SHA1 collisions when we
> say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?
 
There still are non-insignificant number of Internet facing servers that 
require SHA-1 being advertised for connection to be successful.
SHOULD NOT is a good compromise for it.
-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Eric Rescorla]

Yes, we discussed this at IETF 98 and had rough consensus. I'll be merging
this PR this
week

-Ekr


On Fri, Mar 31, 2017 at 6:57 AM, Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:

> Hi,
>
> > I think there is at least another issue that still needs to be
> > discussed: how to properly handle post-handshake handshake messages.
> >
> > The subject has also been raised several times on GitHub
> > (https://github.com/tlswg/tls13-spec/pull/680,
> > https://github.com/tlswg/tls13-spec/pull/676,
> > https://github.com/tlswg/tls13-spec/issues/572) and on the mailing list
> > (https://www.ietf.org/mail-archive/web/tls/current/msg22038.html).
> >
> > Bottom line is:
> > - handling client late authentication requires a lot of state in the
> > client stack
> > - currently, handling client late authentication is mandatory
>
> [...]
>
> > Thus, I believe the current text is inadequate. Different solutions are
> > possible :
> > - remove client late authentication entirely (this would have my
> > preference, since it introduces other issues*)
> > - make client late authentication optional (compatible clients would
> > signal it as an extension)
> > - rethink the client late authentication, as was done with KeyUpdate,
> > to limit the state required on the client side.
>
>
> Martin Thomson proposed a PR (thank you) corresponding to the second
> point, using a simple extension in the ClientHello :
> https://github.com/tlswg/tls13-spec/pull/921/
>
> I believe this proposal is a good trade-off allowing simpler
> implementation designs when late client authentication is not needed.
>
>
> Best regards,
> Olivier Levillain
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Olivier Levillain]

Hi,

> I think there is at least another issue that still needs to be
> discussed: how to properly handle post-handshake handshake messages.
> 
> The subject has also been raised several times on GitHub
> (https://github.com/tlswg/tls13-spec/pull/680,
> https://github.com/tlswg/tls13-spec/pull/676,
> https://github.com/tlswg/tls13-spec/issues/572) and on the mailing list
> (https://www.ietf.org/mail-archive/web/tls/current/msg22038.html).
> 
> Bottom line is:
> - handling client late authentication requires a lot of state in the
> client stack
> - currently, handling client late authentication is mandatory

[...]

> Thus, I believe the current text is inadequate. Different solutions are
> possible :
> - remove client late authentication entirely (this would have my
> preference, since it introduces other issues*)
> - make client late authentication optional (compatible clients would
> signal it as an extension)
> - rethink the client late authentication, as was done with KeyUpdate,
> to limit the state required on the client side.


Martin Thomson proposed a PR (thank you) corresponding to the second
point, using a simple extension in the ClientHello :
https://github.com/tlswg/tls13-spec/pull/921/

I believe this proposal is a good trade-off allowing simpler
implementation designs when late client authentication is not needed.


Best regards,
Olivier Levillain

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls