• No results found

20170919-Reacties-uit-openbare-consultatie-toepassingsgebieden-internet-veiligheidstandaarden

N/A
N/A
Protected

Academic year: 2022

Share "20170919-Reacties-uit-openbare-consultatie-toepassingsgebieden-internet-veiligheidstandaarden"

Copied!
3
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(1)

Pagina 1 van 3

Forum Standaardisatie Wilhelmina van Pruisenweg 52 2595 AN Den Haag

Postbus 96810 2509 JE Den Haag www.forumstandaardisatie.nl

Aan: Forum Standaardisatie

Van: Bureau Forum Standaardisatie

Datum: 13 september 2017 Versie 1.0

Betreft: Overzicht reactie openbare consultatieronde functioneel toepassingsgebieden internet veiligheidstandaarden

Bijlagen: 1. Reactie Networking4all

(2)

Pagina 2 van 3

1. Reactie Networking4all

Van: Sebastian Broekhoven

Verzonden: dinsdag 29 augustus 2017 8:37 Aan: Forum standaardisatie

Onderwerp: Consultatieprocedure functioneel toepassingsgebieden internet veiligheidstandaarden

Beste,

Bij deze wil ik graag reageren op de openbare consultatie.

https://www.forumstandaardisatie.nl/content/openbare-consultatie-functioneel- toepassingsgebieden-internet-veiligheidstandaarden

Vraag 1:

Nee Vraag 2:

Ja, het lijkt mij handig dat er vanuit NCSC een aanbeveling moet komen voor een goed SPF record. Het opstellen van een SPF record met hierin bijvoorbeeld een +all of een ptr: optie helpt niet mee aan de veiligheid. Dus niet alleen het toepassen, maar ook het "goed" toepassen van de standaarden is van belang. Echter heeft SPF nog wel meer nadelen. Zoals het gebruik van aliassen/forwarders op email

adressen.

Vraag 3:

Ja. DKIM toepassen is goed. Echter moet er ook op gelet worden dat de

implementatie goed is. Als de mail binnen komt bij een van de mx-server en DKIM is daar goed, moet de inhoud van de mail onderweg naar de mailbox van de ontvanger niet meer aangepast worden. Want daar gaat DKIM op stuk. Op bijvoorbeeld een server met een virusscanner welke in de body van het bericht plaatst: "E-mail is op virussen gescand door Merk X". Deze informatie kan ook in de header van de e-mail.

Vraag 4:

Het gebruik van DMARC is zeker aan te raden. Wel zal in de toekomst zeker ook gekeken moeten worden naar het ARC-protocol wat problemen met DMARC corrigeert. Het ARC protocol is echter nog jong, het is geboren in 2016. Google gebruikt het al en andere partijen hebben ook aangekondigd dit te implementeren.

Ook al is DMARC geen IETF standaard, het is een project van het Trusted Domain Project welke betrouwbaar is. Hou wel weer rekening met de valkuilen van DMARC.

Omdat DKIM en SPF beide genoeg valkuilen hebben, is het nodig deze te verduidelijken.

Tot nu toe is het advies, gebruik DMARC tot de eerste "hop" waar de mail binnen komt en DMARC gecontroleerd word, gebruik verder daar achter het ARC-protocol.

Dus: DMARC, zeker gebruiken. Kijk echter ook verder naar ARC.

Vraag 5:

Ja, als het duidelijker kan mag het duidelijker. Echter HTTPS / HSTS is natuurlijk altijd iets tussen de client (browser) en de webserver (dmv headers) met de website en applicatie er op.

(3)

Pagina 3 van 3

Vraag 6:

Nee, niet helemaal.

TLS gebruiken tussen applicaties is goed. Het is een standaard welke tussen 2 totaal verschillende applicaties goed kan werken. Het gebruik van IPsec is leuk, maar als dat betekend dat de applicatie niet-versleuteld mag communiceren met een andere applicatie lijkt mij dat niet goed.

DNS over TLS staat nog te veel in de kinderschoenen. Net als bij DNSSEC is dit ook grotendeels afhankelijk van de resolvers bij de instellingen en access providers.

Vraag 7:

Ja, DNSSEC moet gebruikt blijven worden. Wel zijn er nog te veel afhankelijkheden waardoor niet iedereen vanzelfsprekend gebruik maakt van DNSSEC.

Vraag 8:

Ja, standaarden als SPF, DKIM, DMARC, HTTPS+HSTS, TLS en DNSSEC zijn in theorie voor iedereen goed in te zetten. Ook zal dit wel gestimuleerd moeten worden vanuit de overheid. Niet alleen waarom, maar ook de richtlijnen voor het goed gebruiken van deze standaarden.

Andere aankomende standaarden zoals ARC zouden op iets van een roadmap moeten komen. Zo misschien ook de combinatie SMTP/TLS/DANE

Kind regards | Met vriendelijke groet, Sebastian Broekhoven

Product Manager Security Networking4all B.V.

Referenties

GERELATEERDE DOCUMENTEN

Nee, we zijn het niet eens met paragraaf 3.1.3.1 waar gesproken wordt over de kosten voor certificaten en de genoemde afspraak dat voor interne en externe communicatie in

Zijn er volgens u aanvullingen of wijzigingen nodig in paragraaf 1.4 (‘Doorlopen proces’) bezien vanuit het doel om het Forum Standaardisatie en Nationaal Beraad Digitale Overheid

De NLRS heeft een codering bedacht, die niet identiek is met de codering, welke door de generieke standaard (ETIM-MC en EMCS (vanaf EMCS 3.0 zijn deze 2 standaarden aan

Bent u het eens met het advies van de expertgroep om Oauth2.0 met een ‘pas toe of leg uit’-verplichting op te nemen op de lijst met open standaarden nadat er een

Volgende week worden het expertadvies en het advies om de AdES Baseline Profiles op te nemen in de "Pas-toe-of-leg-uit Lijst" voorgelegd in een openbare consultatie..

Is/zijn er volgens u nog andere informatie of overwegingen die aan het Forum en Nationaal Beraad Digitale Overheid zou moeten worden meegegeven voor een besluit over het opnemen

Is/zijn er volgens u nog andere informatie of overwegingen die aan het Forum en Nationaal Beraad Digitale Overheid zou moeten worden meegegeven voor een besluit over het opnemen

In navolging op uw verzoek om input op de openbare consultatie aangaande de wifi beveiligingsstandaard WPA2 Enterprise doe ik u bijgaande