SecDispatch

IETF 115 - London, Room: Kensington 1
17:00 - 18:00 Thursday Session IV (60 minutes)

Agenda

1. Intro and logistics - chairs (5 min)
2. HTTPA2 - Shih-Han (Hans) Wang (15 min)
   https://datatracker.ietf.org/doc/draft-sandowicz-httpbis-httpa2/

3. Secure Routing - Meiling Chen (15 min)
   https://datatracker.ietf.org/doc/draft-chen-secure-routing-requirements/

   https://datatracker.ietf.org/doc/draft-chen-atomized-security-functions/

   https://datatracker.ietf.org/doc/draft-chen-bgp-ls-security-capability/
   4. Signed Public Key and Challenge - Graham Leggett (15 min)
   https://datatracker.ietf.org/doc/draft-leggett-spkac/
   5. TLS-KDH - Tom Vrancken (5 min)
   https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/
   6. Summary and AOB - chairs (5 min)

Minutes

Intro and logistics

No comments.

HTTPA2

Roman Danyliw: Clarifying question: you want to tunnel from the TEE
to the end user, that is the motivation for exra headers
Hans Wang: yes
Hannes Tschofenig: Usually you put tls application gateways to gain
tls acceleration. Why do you not want to go simpliest route to put it to
application level.
Jonathan Hoyland: Why to have TLS channel at all, what security
guarantees you want from the tls.
Hans Wang: you do not necessarely need the TLS channel. In most
scenarios we still trust the TLS.
Jonathan There is no binding between tls and HTTPA, so it is not
needed.
Eric Rescorla: I think this is wrong layer. The right location is
TLS layer, not the HTTP layer. How do you think this will be deployed?
How does client show this to user?
Hans Wang: some browser plugin.
Eric: Is any browser interested in this.
Hans: Not sure yet.
Mark Nottingham: I have significant concerns how this uses http, and
I do not think this is right layer. This is not good name.
Benjamin Schwartz: I just to encourage to check the multilayer work
on http. They can express this in more natural way.
Ted Hardie: Dispatch outcome recommendation: No action at all. If it
stays in http layer it needs to start over.
Daniel Gillmor: Agree in no action. Lots of issue, I am not even
going to start.

Dispatch result: NO ACTION

Secure Routing

Presenter not present, skipped now.

Dispatch result: NOT DISCUSSED

Signed Public Key and Challenge

Michael StJohns: Had seen problems with prooving posession of non
signing keys. Are you also thinking of solving that.
Graham Leggett:* first goal is to solve what is there.
Eric: If not changing format, then correct is AD sponsored.
Jonathan: Correct thing is to use AD sponsored, but if you are
changing from MD5 to something else, then you are changing it.
Graham: There are already implementations using something else than
MD5. There is field telling the hash, but some implementations hard
coded that to be MD5. We do not want to change it.
Robert Moskowitz: There are some things that should be there. For
example timestamps. Perhaps explain what to do for the fact that those
are missing.
Graham: Where go to next. This would be good to be able to change.
Robert: We can just document this is why it is ok to go ahead
without them.
Graham: We could say if you want to have timestamp put it to
challenge.
Deb Cooley: Does this include keygen.
Graham: No
Deb: Then I am not interested.
Daniel Gillmor: Informational. Lack of context is problematic. Add
security considerations listing the things we found out and what
protocols do this right.
Stephen Farrell: Keygen is not part of this?
Graham: Keygen is superset of this. This is the message of sending
the message that I have key.
Stephen: Then what are you going to use this?
Graham: Browser tells he wants to update the key, and then it can
proove that he has the old key before configuring new keys. This is
already in the libraries, so I do not need to write this from the
scratch.
Stephen: There are already lots of implementations like this. I
would say no action.
Roman: To make sure we have documentation of this I will sponsor it
as informational.

Dispatch result: Informational on AD Sponsored

TLS-KDH

Eric Rescorla: Not sure if it is viable, there is no problem in the
conceptually doing this, but is there is enough interest. To the TLS WG.

Alex Chernyakhovsky: Are you using this to authorization and
authentication or both.
Tom Vrancken: Mostly authentication.
Alex: I do not think you should use this for authorizations. Are you
using this for machine to machine case. If using machine to machine,
then why using this.
Tom: No answer to that.
Yoav Nir: We had similar solution in IPsec, and we had almost zero
interest and implementations for it. Is there really someone who is
going to use this.
Tom: There are people in our group who are intersted, also some
interest from radius, and perhaps microsoft.
Jonathan Hoyland: Obvious would be to sent to TLS. This does changes
to TLS key schedule, and breaks assumptions of key schedule. If you do
this we would like to get formal proof.
Tom: we do not think we break anything, but format proof would be
nice.
Jonathan: You are breaking the security proof.
Tom: In the tls-1.3 we generalized the mechanism, and having proof
is something we are interested.
Jonathan: there are also ways to add things to tls key schudule
without breaking security proofs.

Dispatch result: TLS WG

Summary and AOB

Richard Barnes: Summary as follows:

• HTTPA2 - Shih-Han (Hans) Wang (15 min)

  Needs some more thought on how it integrates with the stack
  ... and some more evidence that the folks who would need to be
  engaged are
  No action for now

• Secure Routing - Meiling Chen (15 min)

  no-show

• Signed Public Key and Challenge - Graham Leggett (15 min)

  Informational, via AD sponsorship
  Security considerations might discuss some of the risks Bob raised

• TLS-KDH - Tom Vrancken (5 min)

  Discuss on TLS mailing list
  Would help to know who was intereted in implementing
  Breaks security proofs, see Hoyland's "importer" draft

Roman: You saw our ideas for changing the leadership, and
secdispatch is one of those ongoing working groups. Thank for Richard.

END