Minutes IETF103: saag
minutes-103-saag-00

# SAAG@IETF 103

Time: Thursday 13:50-15:50
Chairs: Eric Rescorla (ekr) and Ben Kaduk

## WG Reports

Slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-saag-chair-slides-00

See the mailling list repo for reports:
https://mailarchive.ietf.org/arch/browse/saag/

* NTP - has sent the NTP security draft to IESG and they would love a review.
* DNSSD is meet at the same time, but the last part of their agenda is
privacy-related. * UTA - has a proposal to drop old versions of TLS for
applications. * DPRIVE - intention to have virtual interim for ADoT. Working on
use cases. * SMART (a research group) - Planning meeting in Pagoda Tonight. 
First 40 get a drink.

## IoT Benchmarking

Slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-saag-iot-benchmarking-00

Sean Turner: It would be helpful to add what class of IoT device is with the
scores; not sure if you can do that. Hannes: You have to provide those details
(processor, ram, flash, etc.) when you submit a score, so you could create a
script.

Alex: Is the focus more on power or performance
Hannes: both
Alex: would expect that some would lean toward power.
Hannes: Cheating is a thing so they're working on verifying the results.
Alex: They are just two profiles - creates a muddled score.
Hannes: Running on higher clock speed it runs faster, slower sometimes mean
longer so more battery drain.

Hannes: One thing that confuses people sometimes is whether the score indicates
it how secure the device is.  IT IS NOT THAT!

## Calls for Assistance

### International Civil Aviation

Planning to use Internet to create an ARKO newtork for network.  Need to
authenticate ground-ground, ground-air, and air-air.  Need trust model that
does not rely on certificates issued by RKTO.  Had two ideas - 1) bridge CA or
2) DNSSEC + TLSA.

BenK: We can probably find some help for you.

## Open Mic

### Publish Nation State Profiles through ISE

Paul W: Recently moved a bunch of Suite B RFCs to historic.  But, we shouldn't
really do any more Nation state RFCs.  THey're going through the ISE.

yoav: IETF publishes April Fool's RFCs, we may not like it, but we publish a
bunch of different RFC's; including publishing brainpool which is a nation
developed algorithm.

Paul W: More specifically, I'm opposed to the IETF publishing RFC's which make
recommendations of using specific algorithms for specific purposes; we want
IETF recommendations, not nation/state recommendations.

ekr: On what ground would the 5742 conflict review block publication for these
profiles.

Sean Turner: We could try publish an RFC that says doesn't publish those type
of RFCs, but the RFC++ BOF outcome was that the IETF can't really tell the ISE
what to do.  It would be hard to get that draft published.

Dmitry Belyavsky: Need a place to get a stable place to put code points.

Kathleen: I agree with ekr + sean.  And I don't think it would help to add
additional process.

Paul W: Not talking about defining ciphers - it's about recommendations of
ciphers.

Kathleen: What published RFCs are there where this is recommended?

Mike: CSNA - outlines a set of algorithms RSA 3k, ecdsa 384, aes256 -- all
algorithms that are alreay used and specificied when used in IETF protocols.

Dan Harkins: It's already specified.  It's not defining anything new; it's
actually generally recommended algorithms/parameters

Stephen F: We can't tell him what to do.  THere was some utility in the earlier
Suite  B documents -- I'm not sure we need it anymore.  We don't want to be in
the business of national specific stuff.

Wes Hardaker: Two issues 1) The instant you say you can't publish something
we're doing censorship, 2) some people will need code points - we need to
support that.  There is confusion with RFC #s and whether they indicate IETF
consensus.  Two things we can do 1) we can publish an RFC that says don't do
this or that, 2) we need to fix perception problem.

Vasily Dolmatov: Wes stole my show.  Real world decides which standardsa are
implemented - and this is a good thing. I would like to give them to present
some solution.

BenK: NSA has multiple publication venues: ISE and their own. But that's really
up to them and the publisher.

Adrian (the ISE): Paul and I didn't synch up, but that was maybe a good thing.
I'm not paid to do ISE work, thus not seeking more drafts to publish ;) I would
prefer that everything that came to me could back to the IETF and get published
as a WG document.  For cipher suites, I know that there's a research group that
could make a statement that this is "not known to be broken", and I would even
prefer "known to be good".  Code points are somewhere in the middle, if that
registry says you can only get throug the IETF that's easy - if it's FCFS then
it's already been applied.  This one is a profile - if this is of benefit for
the Internet as a whole or part of it - it should be published.  Publishing
supports vendors that sell there and an understanding of what a good profile is
(i.e., it gives them a template).  Can you tell me what to do?  The exent to
which I listen is based on your arguement.  I factor in the reviews I get, and
I do require external reviews before I publish anything.

### GET WELL CARD FOR BOB

Rich: There's a card for Bob Moskowitz - sign the card please.

### Root KSK Signing

Paul Hoffman: DNSSEC KSK was rolled - not much bustage.  Looking for more input
about how often to do it, as this affects (perceptions of) the security
provided by DNSSEC.  Tomorrow at 9 - on the side meeting schedule.

### I2NSF

Yoav: we need help with a draft for configuring ipsec gateways using an  SDN
controller, and the YANG model for this draft is probably just straight from a
linux header and has every algorithm ever.  The list needs pruning; please
help!  Understanding IPSEC is a plus, but any crypto understanding will do, to
get us to just things we want in 2018, not things we want in 1998.  Thank you,
Paul!