Ecosyste.ms: Repos

An open API service providing repository metadata for many open source software ecosystems.

GitLab.com / dkg / pep-internet-drafts

A clone of the PEP project's [Internet Drafts repository](https://gitea.pep.foundation/pEp.foundation/internet-drafts.git)

JSON API: https://repos.ecosyste.ms/api/v1/hosts/GitLab.com/repositories/dkg%2Fpep-internet-drafts

Stars: 0
Forks: 0
Open Issues: 0

License: None
Language:
Dependencies: 2,909

Created: almost 4 years ago
Updated: 10 months ago
Last synced: 10 months ago

Files

Loading...

Readme

Loading...

Dependencies

inactive/ietf-lamps-hp-requirements/archive/draft-ietf-lamps-header-protection-requirements-00.txt pypi

1.1.RequirementsLanguage *
1.1.RequirementsLanguage..................4 *
1.2.Terms *
1.2.Terms..........................4 *
1.Ifaheaderfieldisbeingencryptedbecauseitissensitive ,its
1.Introduction *
1.Introduction........................3 *
1.Theouterheaderfieldsmightbetamperedwith ,soareceiving
10.IANAConsiderations *
10.IANAConsiderations.....................17 *
11.Acknowledgments *
11.Acknowledgments.......................17 *
12.1.NormativeReferences *
12.1.NormativeReferences..................17 *
12.2.InformativeReferences *
12.2.InformativeReferences.................18 *
12.References *
12.References.........................17 *
14CastleMews *
2.ProblemStatement *
2.ProblemStatement......................4 *
2.TheouterheadersectionSHOULDbeminimalinordertoavoid *
3.1.Interactions *
3.1.Interactions......................5 *
3.2.ProtectionLevels *
3.2.ProtectionLevels....................6 *
3.The *
3.UseCases *
3.UseCases..........................5 *
4.1.1.SendingSide *
4.1.1.SendingSide....................7 *
4.1.2.ReceivingSide *
4.1.2.ReceivingSide...................7 *
4.1.GeneralRequirements *
4.1.GeneralRequirements..................6 *
4.2.1.Sendingside *
4.2.1.Sendingside....................8 *
4.2.2.Receivingside *
4.2.2.Receivingside...................8 *
4.2.AdditionalRequirementsforBackward-CompatibilityWith *
4.2.AdditionalRequirementsforBackward-CompatibilityWithLegacy *
4.3.1.SendingSide *
4.3.1.SendingSide....................9 *
4.3.2.ReceivingSide *
4.3.2.ReceivingSide...................9 *
4.3.AdditionalRequirementsforBackward-Compatibilitywith *
4.3.AdditionalRequirementsforBackward-CompatibilitywithLegacy *
4.Requirements *
4.Requirements........................6 *
4rev1 *
5.1.Option1 *
5.2.1.Content-TypeParameter *
5.2.Option2 *
5.3.Option2.1 *
5.4.1.Option1 *
5.4.2.Option2 *
5.4.3.Option2.1ProgressiveHeaderDisclosure *
5.4.3.Option2.1ProgressiveHeaderDisclosure......14 *
5.4.Examples *
5.4.Examples........................11 *
5.OptionstoAchieveHeaderProtection *
5.OptionstoAchieveHeaderProtection............9 *
6.1.CandidateHeaderFieldsforHeaderProtection *
6.1.CandidateHeaderFieldsforHeaderProtection......14 *
6.SendingSideConsiderations *
6.SendingSideConsiderations.................14 *
7.1.WhichHeaderFieldstoDisplaytoUser *
7.1.WhichHeaderFieldstoDisplaytoUser.........16 *
7.2.MailUserAgentAlgorithmfordecidingwhichversionofa *
7.2.MailUserAgentAlgorithmfordecidingwhichversionofaheader *
7.ReceivingSideConsiderations *
7.ReceivingSideConsiderations................16 *
8.SecurityConsiderations *
8.SecurityConsiderations...................16 *
9.PrivacyConsiderations *
9.PrivacyConsiderations...................17 *
Abstract *
Additionallyitdraftspossiblesolutionstoaddressthechallenge. *
AlexeyMelnikov *
AppendixA.DocumentChangelog *
AppendixA.DocumentChangelog.................18 *
AppendixB.OpenIssues *
AppendixB.OpenIssues....................19 *
Arangeofprotocolsfortheprotectionofelectronicmail *
Astandardforend-to-endprotectionoftheemailheaderssection *
Authentication ,Reporting,andConformance
AuthorizingUseofDomainsinEmail ,Version1
Authors *
B1 *
BR1 *
BS1 *
BS2 *
BS3 *
BernieHoeneisen *
Bodies *
Butnotethathavingkeyheaderfieldsduplicatedintheouter *
CH-8046Zuerich *
ClientsUnawareofHeaderProtection *
Content-Transfer-Encoding *
Content-Type *
Content-Typeparameter *
Copyright *
CopyrightNotice *
DOI10.17487 *
Date *
DavidWilsoncameupwiththeideaofdefininganewContent-Type *
Disclosure *
Email *
EmailHeaders *
End-to-endprotectionfortheemailheaderssectioniscurrentlynot *
Essentialpartsof havebeen
Examplesinsubsequentsectionsassumethatanemailclientistrying *
Expires *
Extensions *
FYI36 ,RFC4949,DOI10.17487
FeedbackfromIETF-104 *
Finally ,somebestpracticesarecollected.
Forasigned-onlymessage ,itisRECOMMENDEDthatall
Forbackwardcompatibilityoflegacyclients-unawareofanyHP- *
From *
G1 *
G2 *
G3 *
G4 *
GR1 *
GR2 *
GS1 *
GS2 *
GS3 *
GS4 *
Hampton ,MiddlesexTW122NP
HeaderProtectionSystems *
However ,thefinalsolutionwillbedeterminedbytheIETFLAMPSWG.
Ifyes ,considerimprove
Inordertoprotectouter ,non
Instructionsin describinghowtoprotecttheEmailmessage
Intendedstatus *
Internet-DraftHeaderProtectionrequirementsJuly2019 *
Internet-DraftIsodeLtd *
Internet-Draftsaredraftdocumentsvalidforamaximumofsixmonths *
Internet-DraftsareworkingdocumentsoftheInternetEngineering *
Inthefollowing ,weshowthegenericusecasesthatneedtobe
Inthefollowingalistofrequirementsthatneedtobeaddressed *
InthefollowingasetofOptionstoachieveEmailHeaderProtection. *
IsodeLtd *
ItisexpectedthattheIETFLAMPSWGchoosesanoptiontoupdate *
July08 ,2019
LS1 *
LS2 *
LSR1 *
LSS1 *
LSS2 *
LegacyClientsUnawareofHeaderProtection.......8 *
LegacyHeaderProtectionSystems *
Luck ,C.,
Luck.ForfurtherAcknowledgments ,pleaserefertoAcknowledgments
MIME-Version *
MIMEentityhasaContent-Typeofmessage *
MIMEheaderfields *
MMHS-Primary-Precedence *
Marques ,H.,
Melnikov *
MemoryHoleapproachworksbycopyingthenormalmessageheader *
Message-ID *
MessageAuthentication ,Reporting,andConformance
MessageSpecification *
Moreinformationonprogressiveheaderdisclosurecanbefoundin *
MultipurposeInternetMailExtensions *
NetworkWorkingGroupA.Melnikov *
NomechanismforheaderprotectionhasbeenstandardizedforPGP *
Note *
Notethatrecommendationslistedabovetypicallyonlyapplytonon *
Notethattheaboverecommendationscanalsonegativelyaffectanti- *
October2018. *
OneofthegoalsofthisdocumentistospecifyUIfordisplaying *
Phone *
PrivacyandsecurityissueswithemailheaderprotectioninS *
ProblemStatementandRequirementsforHeaderProtection *
Protocols *
ProvisionsRelatingtoIETFDocuments *
RFC6376 ,DOI10.17487
RequirementLevels *
SHOULDNOTbeincludedintheouterheader *
SHOULDeitherbeidenticaltotheinner *
SeveralLAMPSWGparticipantsexpressedtheopinionthatwhatever *
SincetheMIMEbodypartheadersectionisitselfcoveredbythe *
StatusofThisMemo *
Subject *
Switzerland *
TableofContents *
TaskForce *
TheLAMPSchartercontainsthefollowingWorkItem *
Theauthorswouldliketothankthefollowingpeoplewhohave *
ThecurrentpEpproposalisforPGP *
Thedocumentisnotdefiningnewprotocol ,soitdoesn
Thefollowingexampledemonstrateshowheadersectionandpayloadof *
Thefollowingintermediateusecasesmayneedtobeconsideredas *
Thefollowingprotectionlevelsneedtobeconsidered *
Thefollowingtermsaredefinedforthescopeofthisdocument *
Thekeywords *
ThemaininteractioncaseforHeaderProtection *
TheneedformeansofDataMinimization ,whichincludesdata
ThepEpmessageformatisequivalenttotheS *
ThisInternet-Draftissubmittedinfullconformancewiththe *
ThisInternet-DraftwillexpireonJanuary9 ,2020.
ThisdocumentdefinesanewContent-Typeheaderfieldparameter *
Thisdocumentdescribestheproblemstatement ,genericusecases
Thisdocumentdescribestheproblemstatement ,genericusecases,and
ThisdocumentissubjecttoBCP78andtheIETFTrust *
ThisdocumentrequestsnoactionfromIANA. *
ThisdocumenttalksaboutUIconsiderations ,includingsecurity
ThisisamultipartmessageinMIMEformat. *
ThisisanimportantmessagethatIdon *
Thislookssimilarasinoption2.Specificexamplescanbefoundin *
ThisoptionissimilartoOption2 *
Thissectionoutlineshowthenew *
Thissub-sectionaddressestheusecases2 *
Thissub-sectionaddressestheusecases5 *
Thissubsectionislistingtherequirementstoaddressusecase1 *
To *
UK *
UcomStandardsTrackSolutionsGmbH *
Updatethespecificationforthecryptographicprotectionofemail *
WhenanS *
WhendisplayingS *
Whengeneratingencryptedorencrypted *
Wilson ,SteveKille,WeiChuang,andRobertWilliams
Withoutmessageheaderprotectionthecorrespondingsignedmessage *
Wrappingwithmessage *
X-Mailer *
addressedindependentlyofwhetherS *
alsoapplicabletoPGP *
and *
andSenderPolicyFramework *
andaimtominimizetheimplementationefforttoincludesupport *
andarenotcapableofprovidingprivacyfortheinformation *
andhowheadersectionwrappingworks *
andistrusted. *
andmaybeupdated ,replaced,orobsoletedbyotherdocumentsatany
andselectivelymodifiescommunicateddatatomasqueradeasoneor *
andthenprependingthemwith *
andwithenclosedsignatureandnecessarypublickeyssothatreplies *
aprotectbodypartmightlooklike.Forexample ,thiswillbethe
atleastforsignedonlyemail. *
beforepublication. *
being *
bodypart ,extractheaderfieldsfromitandpropagatethemtothe
canbeimmediatelyupgradedtoencryptedmessages. *
carefully ,astheydescribeyourrightsandrestrictionswithrespect
changesintheexistingcodebase.InparticularalsoMIME *
cleartextwithoutsignatureorencryption ,ortransferthemencrypted
clientSHOULDignorethem ,unlesstheyareprotectedinsome
clientsthatcan *
conflictinginformationbetweentheprotectedandunprotected *
conflictwithanynewsolutionforHPatallorwhether *
considerations ,whenprocessingmessagesprotectingheaderfields.
containedtherein. *
containingSignedDatamessagewhichdoesn *
containthetruevalue *
content-type *
copied ,butalsothecontent.
correspondingoutervaluemustbeignored *
cryptographically-protectedelectronicmailprotectonlythebody *
decidehowtopresentthis *
defaultbeingthatwhateverisnotneededfromGS2isnotput *
degree *
describedintheSimplifiedBSDLicense. *
designatedaslegacyHP *
destinationheaderfieldismandatoryasper .
disclosureofconfidentialinformation.Itisrecommendedthat *
document *
documentaretobeinterpretedasdescribedin .
documentauthors.Allrightsreserved. *
doesnotsupportanyHP *
draft-ietf-lamps-header-protection-requirements-00 *
easilyimplementable.Unlessneededformaximizingprotectionand *
electronicmail.Mostcurrentimplementationsof *
email ,donotofferfullend
emailheaderssectionorselectedheaderfieldsfromthedomain-level *
encapsulatedandforwardedemails. *
encapsulatedmessagesusingnewHPmechanism. *
encrypted *
encryptedemail. *
encryptedpayloadoftheapplication *
encryption.Technicallyitisalsopossibletosign ,butnot
encrypttheprotectedmessages.Thisneedsfurtherstudy. *
ensuringheaderprotection ,inthatthewholemessageisprotected
exist ,whichallowtoassesstheauthenticityandintegrityofthe
existsforS *
fieldparametercouldbedefined *
fields *
fieldsareidenticaltothe *
fieldsintotheMIMEheadersectionofthetoplevelprotectedbody *
fieldsshouldbeomittedandreplacedwith *
fieldtodisplay *
firstbodypartofamultipart *
forexistingsolutions. *
foritsinnermostmessagestructure.Securitycomesjustnextafter *
formofactivewiretappingattackinwhichtheattackerintercepts *
forwarded =no
forwardedmessageandnotaconstructcreatedsolelytoprotectthe *
forwardedmessages ,legacyencapsulatedmessages,and
forwardedmessagesandencapsulatedmessagesusingnewHP *
frequentlyusedbyIMAPclientsinordertoavoidparsingmessage *
fullysupportsHP *
guessed. *
havebeenidentifiedforsometime.However ,thedesiretofixthese
header. *
headerfieldismandatoryaccordingto ,astubvalue
headerfieldisonlypresentintheouterheader ,itMAYbe
headerfieldparametertodistinguishforwardedmessagesfrominner *
headerfieldprotectionconstructs. *
headerfieldtodisplay.................16 *
headerisconvenientformanymessagestores *
headers-bothforsignaturesandencryption-toimprovethe *
headers. *
headersection ,bywrappingthemessageinsideamessage
ignored *
implementationsituationwithrespecttoprivacy ,security,
includeSimplifiedBSDLicensetextasdescribedinSection4.eof *
independentlyofwhetherS *
indicatorthatitisnottrustworthy *
innerheadersection. *
insensitiveandcanbeeither *
insertionofpublickeys ,therootentityoftheprotectedmessageis
instead ,bywrappingitandprovidingcryptographicservicestothe
inthecasethatthe *
intotheunencryptedtransportheaders ,thusfulfillingdata
issuehasbeenexpressedintheIETFLAMPSWorkingGrouponly *
issuesaspreviouslydiscussed. *
it. *
layer.I.e.thisisamessagewhichisnotencryptedandnot *
levelprotectbodypart *
librarieswidelyusedshallnotneedtobechangedtocomplywith *
maintained. *
materialortocitethemotherthanas *
mechanism. *
mechanismwillbechosen ,itshouldnotbelimitedtoS
mergedintothisdocument.SpecialthankstoitsauthorClaudio *
message *
messages. *
mightlooklikethis. *
minimizationrequirements *
moreoftheentitiesinvolvedinacommunicationassociation. *
needtodocumentthecase. *
newsecurityconcernsnotalreadycoveredbyS *
normalmessageheaderfieldsintotheMIMEheadersectionofthetop *
notsupportanyHP *
oAddexampletoSection5.4.3 *
oAddmoretextonMemoryHole *
oCorrectterminologyforHeader *
oDecideinwhichformlegacyHPrequirementsshouldremaininthis *
oEnhanceIntroductionandProblemStatementsections *
oHeaderField *
oHeaderSection *
oMan-in-the-middle *
oRephraseSection5.2 *
oResolvequestionregardingBccinSection6.1 *
oRewriteSection6.1 *
oShouldrequirementG3remain *
oSigned-onlymessage *
oSigned-onlyprotectionneedsfurtherstudy *
oWriteSection7.2 *
odraft-ietf-lamps-header-protection-requirements-00 *
ofallinformationthattechnicallycanbehidden *
ofthemessage ,whichleavessignificantroomforattacksagainst
onlytheinnerheaderfieldvalueMUSTbedisplayed *
orguessed. *
otherway *
otherwise-protectedmessages. *
pEpforemail definesafixedMIMEstructure
pEphasalsoimplementedtheabove *
parameters ,suchas
parametersetto *
part.SincetheMIMEbodypartheadersectionisitselfcoveredby *
particular ,Subject
particular ,Keywords,In
particulardowngradeattacks ,canbedetected.
particulardowngradeattacks ,aremitigatedasgoodaspossible.
perspective ,specificallyDomainKeysIdentifiedMail
prependedby *
privacy ,existingimplementationsshallnotrequiresubstantial
privacyinpEp ,forwhichreasontheapplicationofsignatures
progress ,andwillsubstantiallychangeinfuturerevisions.
protectheaderfields *
protectionmechanisms *
protectionsofthemessagebody. *
protocols ,whileessentialtorespondingtoarangeofattackson
providedhelpfulcommentsandsuggestionsforthisdocument *
provideheaderprotection.ThisentitySHOULDbepresentedasthe *
provisionsofBCP78andBCP79. *
publicationofthisdocument.Pleasereviewthesedocuments *
purposeful.pEpforemail ,eitherexpectstotransfermessagesin
recently.TheexistingS *
recipients *
regardingheaderprotection. *
replacedwiththeirprotectedversionswhendisplayedtotheuser. *
requirements.Additionallyitdraftspossiblesolutionstoaddress *
returnedinIMAPENVELOPEFETCHdataitem ,whichis
rfc822container arethusupdatedtoread
sectionof .
secure. *
sensitive ,toMonday9amofthesameweek
sidefullysupportsHP *
someotherway ,forexamplewithaDKIMsignaturethatvalidates
spamprocessing. *
sparenessandthehidingofalltechnicallyconcealableinformation *
specificimplementations. *
structure ,Content
suchmessageswhichislessconfusing *
supportslegacyHPonly *
technologyisusedforwhichHeaderProtection *
theTrustLegalProvisionsandareprovidedwithoutwarrantyas *
thechallenge.Finallysomebestpracticesarecollected. *
thefollowingintermediateinteractionsneedtobeconsideredas *
themessagenestedinside *
thenewmechanismforHP. *
theouterheadersectiononlycontains *
theprotectionmechanisms *
theyaresigned-only ,encryptedorencrypted
thisdocument. *
thusnestedoncemoreintoanadditionalmultipart *
time.ItisinappropriatetouseInternet-Draftsasreference *
to. *
tobeimplemented. *
tobeincludedintheouterheadersection. *
tobeusedfordisplay *
top-levelmessage ,takingintoaccountheadersectionmerging
toplevel.Thisshouldalsoworkfortriple-wrappedmessages. *
toprotect *
totheseheaderfields. *
totheseheaderfields.Itisuptothereceivingclientto *
tothisdocument.CodeComponentsextractedfromthisdocumentmust *
truevalueMUSTNOTbeincludedintheouterheader.Ifthe *
unprotected *
usabilityandinteroperabilityincryptographically-protected *
usedtoapplyHPto. *
usetheContent-Typeparameter *
value ,orcontainaclearindicationthattheoutervalueisnot
valueasintheinnerheaderfield ,or,iftheDatevalueisalso
verifywhetherthisrequirementappliesgenerallyorjustfor *
visibleheader *
well *
wellforbackwardcompatibilitywithlegacyHPsystems ,suchas
wheneverpossible ,hasgrowninimportanceoverthepastyears.
wholeoriginalmessage.However ,forthepurposeofallowingthe
widelyimplemented-neitherformessagesprotectedbymeansof *
withoutencryptiontomessagesintransitisnotconsidered *
withoutthe *
workingdocumentsasInternet-Drafts.ThelistofcurrentInternet- *
wouldmeanthatallheaderfieldsaresigned.Inthiscase ,the
wrapper. *

inactive/ietf-lamps-hp-requirements/archive/draft-ietf-lamps-header-protection-requirements-01.txt pypi

1.1.RequirementsLanguage *
1.1.RequirementsLanguage..................4 *
1.2.Terms *
1.2.Terms..........................4 *
1.Ifaheaderfieldisbeingencryptedbecauseitissensitive ,its
1.Introduction *
1.Introduction........................3 *
1.ThemessagefortherecipientaddresseslistedinToorCcheader *
1.Theouterheaderfieldsmightbetamperedwith ,soareceiving
14CastleMews *
2.1.Privacy *
2.1.Privacy.........................4 *
2.2.Security *
2.2.Security........................5 *
2.3.Usability *
2.3.Usability........................5 *
2.4.Interoperability *
2.4.Interoperability....................5 *
2.ProblemStatement *
2.ProblemStatement......................4 *
2.Themessage *
2.TheouterheadersectionSHOULDbeminimalinordertoavoid *
3.1.Interactions *
3.1.Interactions......................5 *
3.2.ProtectionLevels *
3.2.ProtectionLevels....................6 *
3.The *
3.Themessagestoredinthe *
3.UseCases *
3.UseCases..........................5 *
4.1.1.SendingSide *
4.1.1.SendingSide....................7 *
4.1.2.ReceivingSide *
4.1.2.ReceivingSide...................8 *
4.1.GeneralRequirements *
4.1.GeneralRequirements..................7 *
4.2.1.Sendingside *
4.2.1.Sendingside....................8 *
4.2.2.Receivingside *
4.2.2.Receivingside...................9 *
4.2.AdditionalRequirementsforBackward-CompatibilityWith *
4.2.AdditionalRequirementsforBackward-CompatibilityWithLegacy *
4.3.1.SendingSide *
4.3.1.SendingSide....................9 *
4.3.2.ReceivingSide *
4.3.2.ReceivingSide...................9 *
4.3.AdditionalRequirementsforBackward-Compatibilitywith *
4.3.AdditionalRequirementsforBackward-CompatibilitywithLegacy *
4.Requirements *
4.Requirements........................7 *
4rev1 *
5.SecurityConsiderations *
5.SecurityConsiderations...................9 *
6.PrivacyConsiderations *
6.PrivacyConsiderations...................10 *
7.IANAConsiderations *
7.IANAConsiderations.....................10 *
8.Acknowledgments *
8.Acknowledgments.......................10 *
9.1.NormativeReferences *
9.1.NormativeReferences..................10 *
9.2.InformativeReferences *
9.2.InformativeReferences.................11 *
9.References *
9.References.........................10 *
A.1.1.Option1 *
A.1.2.1.Content-TypeParameter *
A.1.2.Option2 *
A.1.3.Option2.1 *
A.1.4.1.Option1 *
A.1.4.2.Option2 *
A.1.4.3.Option2.1ProgressiveHeaderDisclosure *
A.1.4.Examples *
A.1.4.Examples......................14 *
A.1.OptionstoAchieveHeaderProtection *
A.1.OptionstoAchieveHeaderProtection..........12 *
A.2.1.CandidateHeaderFieldsforHeaderProtection *
A.2.1.CandidateHeaderFieldsforHeaderProtection....20 *
A.2.SendingSideConsiderations *
A.2.SendingSideConsiderations...............20 *
A.3.1.WhichHeaderFieldstoDisplaytoUser *
A.3.1.WhichHeaderFieldstoDisplaytoUser.......22 *
A.3.2.MailUserAgentAlgorithmfordecidingwhichversion *
A.3.2.MailUserAgentAlgorithmfordecidingwhichversionofaheader *
A.3.ReceivingSideConsiderations *
A.3.ReceivingSideConsiderations..............21 *
Abstract *
AlexeyMelnikov *
AppendixA.1.2.1 *
AppendixA.ImplementationConsiderations *
AppendixA.ImplementationConsiderations...........12 *
AppendixB.DocumentChangelog *
AppendixB.DocumentChangelog.................22 *
AppendixC.OpenIssues *
AppendixC.OpenIssues....................23 *
Arangeofprotocolsfortheprotectionofelectronicmail *
Astandardforend-to-endprotectionoftheemailheadersection *
AuthorizingUseofDomainsinEmail ,Version1
Authors *
B1 *
BR1 *
BS1 *
BS2 *
BS3 *
BernieHoeneisen *
Bodies *
Butnotethathavingkeyheaderfieldsduplicatedintheouter *
CH-8046Zuerich *
CertainimplementationsMAYdecidetosend *
ClientsUnawareofHeaderProtection *
Content-Transfer-Encoding *
Content-Type *
Content-Typeparameter *
Copyright *
CopyrightNotice *
DOI10.17487 *
Date *
DavidWilsoncameupwiththeideaofdefininganewContent-Type *
Disclosure *
Email *
EmailHeaders *
Essentialpartsof havebeen
Examplesinsubsequentsectionsassumethatanemailclientistrying *
Expires *
Extensions *
FYI36 ,RFC4949,DOI10.17487
Fora *
Forbackwardcompatibilityoflegacyclients-unawareofanyHP- *
From *
G1 *
G2 *
G3 *
G4 *
GR1 *
GR2 *
GR3 *
GS1 *
GS2 *
GS3 *
GS4 *
Group.TheexistingS *
HFs. *
Hampton ,MiddlesexTW122NP
HeaderProtectionSystems *
Inordertoprotectouter ,non
Instructionsin describinghowtoprotecttheEmailmessage
Intendedstatus *
Internet-DraftHeaderProtectionrequirementsOctober2019 *
Internet-DraftIsodeLtd *
Internet-Draftsaredraftdocumentsvalidforamaximumofsixmonths *
Internet-DraftsareworkingdocumentsoftheInternetEngineering *
Inthefollowingalistofthegenericusecasesthatneedtobe *
Inthefollowingasetofchallengestobeaddressed *
Inthiscase ,the
IsodeLtd *
LS1 *
LS2 *
LSR1 *
LSS1 *
LSS2 *
LegacyClientsUnawareofHeaderProtection.......8 *
LegacyHeaderProtectionSystems *
Luck ,C.,
Luck.ForfurtherAcknowledgments ,pleaserefertoAcknowledgments
MIME andEmail
MIME-Version *
MIMEentityhasaContent-Typeofmessage *
MIMEheaderfields *
MMHS-Primary-Precedence *
Marques ,H.,
Melnikov *
Message-ID *
MessageAuthentication ,Reporting,andConformance
MessageSpecification *
Messagescontainingacryptographicsignature ,butwhichno
Messagescontainingacryptographicsignaturewhicharealso *
MessagescontainingatleastonerecipientaddressintheBccheader *
Messagesthatencryptionisappliedtowhichdonotcontaina *
Moreinformationonprogressiveheaderdisclosurecanbefoundin *
MultipurposeInternetMailExtensions *
NetworkWorkingGroupA.Melnikov *
Nomechanismforheaderprotection *
Note *
Notethatrecommendationslistedabovetypicallyonlyapplytonon *
Notethattheaboverecommendationscanalsonegativelyaffectanti- *
October2018. *
October28 ,2019
OneofthegoalsofthisdocumentistospecifyUIfordisplaying *
Phone *
PrivacyandsecurityissueswithemailheaderprotectioninS *
ProblemStatementandRequirementsforHeaderProtection *
Protection.TheIETFLAMPSWGmaychoosefromtheseoptionsinorder *
Protocols *
ProvisionsRelatingtoIETFDocuments *
RFC6376 ,DOI10.17487
RegardingtheBccheaderfieldthereshouldbenodifferencebetween *
RequirementLevels *
SHOULDNOTbeincludedintheouterheader *
SHOULDeitherbeidenticaltotheinner *
Section3.1 *
Section3.2 *
Sectionsforsignaturesandencryption *
SendingandreceivingsideSHOULDimplement *
Severalvaryingimplementationsofend-to-endprotectionsforemail *
SomeLAMPSWGparticipantsexpressedtheopinionthatwhatever *
StatusofThisMemo *
Subject *
Switzerland *
TableofContents *
TaskForce *
Thayer ,
TheLAMPSchartercontainsthefollowingWorkItem *
TheMemoryHoleapproachworksbycopyingthenormalmessageheader *
Theauthorswouldliketothankthefollowingpeoplewhohave *
ThecurrentpEpproposalisforPGP *
Thedocumentdoesnotdefineanewprotocol ,andthusdoesnotcreate
ThefollowingarecurrentoptionsforaddressingEmailHeader *
Thefollowingexampledemonstrateshowheadersectionandpayloadof *
Thefollowingintermediateusecasesmayneedtobeconsideredas *
Thefollowingisalistofrequirementsthatneedtobeaddressed *
Thefollowingprotectionlevelsneedtobeconsidered *
Thefollowingtermsaredefinedforthescopeofthisdocument *
Thekeywords *
ThemaindifferencecomparedtoOption2isanadditionalmultipart *
ThemaininteractioncaseforHeaderProtection *
TheneedformeansofDataMinimization ,whichincludesdata
ThepEpmessageformatisequivalenttotheS *
ThisAppendixAcontainsadditionalinformationandconsiderations *
ThisInternet-Draftissubmittedinfullconformancewiththe *
ThisInternet-DraftwillexpireonApril30 ,2020.
ThisdocumentdefinesanewContent-Typeheaderfieldparameter *
Thisdocumentdescribestheproblemstatement *
Thisdocumentdescribestheproblemstatement ,genericusecases,and
ThisdocumentissubjecttoBCP78andtheIETFTrust *
ThisdocumentrequestsnoactionfromIANA. *
ThisdocumenttalksaboutUIconsiderations ,includingsecurity
ThisisamultipartmessageinMIMEformat. *
ThisisanimportantmessagethatIdon *
ThisoptionissimilartoOption2 *
Thissectionoutlineshowthenew *
To *
UK *
UcomStandardsTrackSolutionsGmbH *
Updatethespecificationforthecryptographicprotectionofemail *
WhenanS *
WhendisplayingS *
WhengeneratingS *
Wilson ,KellyBristol,RobertWilliams,SteveKille,andWeiChuang.
Withoutmessageheaderprotectionthecorrespondingsignedmessage *
Wrappingwithmessage *
X-Mailer *
addressedformessageswithHeaderProtection *
alsoapplicabletoPGP *
and *
andReceivingsidesSHOULDimplement *
andadjustedtotheaboveS *
andaimtominimizetheimplementationefforttoincludesupport *
andhowheadersectionwrappingworks *
andistrusted. *
andmaybeupdated ,replaced,orobsoletedbyotherdocumentsatany
andselectivelymodifiescommunicateddatatomasqueradeasoneor *
andthenprependingthemwith *
andwithenclosedsignatureandnecessarypublickeyssothatreplies *
anynewsecurityconcernsnotalreadycoveredbyS *
applyindependentlyofwhetherS *
aprotectbodypartmightlooklike.Forexample ,thiswillbethe
arefurtherexplainedinSection3.2. *
aretobetreated. *
asforillustrativepurpose.Specificexamplescanbefoundin *
basedMessageAuthentication ,Reporting,andConformance
beforepublication. *
being *
bodypart ,extractheaderfieldsfromitandpropagatethemtothe
by *
canbeimmediatelyupgradedtoencryptedmessages. *
carefully ,astheydescribeyourrightsandrestrictionswithrespect
challengeandsomebestpracticesarecollected.Inanycase ,the
changesintheexistingcodebase.InparticularalsoMIME *
cleartextwithoutsignatureorencryption ,ortransferthemencrypted
clientSHOULDignorethem ,unlesstheyareprotectedinsome
clientsthatcan *
conflictinginformationbetweentheprotectedandunprotected *
conflictwithanynewsolutionforHPatallorwhether *
considerations ,whenprocessingmessagesprotectingHeaderFields.
containthetruevalue *
copied ,butalsothecontent.
correspondingoutervaluemustbeignored *
cryptographically-protectedelectronicmailprotectonlythebody *
cryptographicsignature. *
decidehowtopresentthis *
degree *
dependingonthecircumstancesandcustomerrequirements.Sending *
derived. *
describedintheSimplifiedBSDLicense. *
designatedaslegacyHP *
destinationheaderfieldismandatoryasper .
differ ,theycansimplybereplacedwiththeirprotectedversions
disclosureofconfidentialinformation.Itisrecommendedthat *
document *
documentaretobeinterpretedasdescribedin .
documentauthors.Allrightsreserved. *
doesnotsupportanyHP *
donotsupportS *
draft-ietf-lamps-header-protection-requirements-01 *
easilyimplementable.Unlessneededformaximizingprotectionand *
electronicmail.Mostcurrentimplementationsof *
emailheaderssectionorselectedheaderfields *
emails. *
encapsulatedandforwardedemails. *
encapsulatedemailsusingnewHPmechanism. *
encrypted. *
encryptedpayloadoftheapplication *
encryption *
encryptionapplied. *
encryptionisappliedto. *
encryptiontoprotectheaderfields *
ensuringheaderprotection ,inthatthewholemessageisprotected
exist ,whichallowtoassesstheauthenticityandintegrityofthe
existsforS *
field ,whichdependsontheimplementation
fieldmayappearinuptothreedifferentvariants *
fieldparametercouldbedefined *
fields ,whichmustnotincludetheBccheaderfieldneitherfor
fields *
fieldsintotheMIMEheadersectionofthetoplevelprotectedbody *
fieldsshouldbeomittedandreplacedwith *
fieldtodisplay *
finalsolutionistobedeterminedbytheIETFLAMPSWG. *
firstbodypartofamultipart *
for *
forexistingsolutions. *
foritsinnermostmessagestructure.Securitycomesjustnextafter *
formofactivewiretappingattackinwhichtheattackerintercepts *
forwarded =no
forwardedemails ,legacyencapsulatedemails,and
frequentlyusedbyIMAPclientsinordertoavoidparsingmessage *
fullysupportsHP *
global *
havebeenidentifiedforsometime.However ,thedesiretofixthese
header. *
headerfieldismandatoryaccordingto ,astubvalue
headerfieldisonlypresentintheouterheader ,itMAYbe
headerfieldparametertodistinguishforwardedmessagesfrominner *
headerfieldprotectionconstructs. *
headerfields.Andinthecasethatthe *
headerfields.Thiswouldmeanthatallheaderfieldsaresigned. *
headerisconvenientformanymessagestores *
headers-bothforsignaturesandencryption-toimprovethe *
headersection ,bywrappingthemessageinsideamessage
headersectionandarenotcapableofprovidingprivacyforthe *
headersectionsexist ,thoughthetotalnumberofsuch
i.e.withallrecipientaddresses. *
identicalto1. *
ignored *
implementationdocument. *
implementationsappearstoberatherlow. *
implementationsituationwithrespecttoprivacy ,security,
includeSimplifiedBSDLicensetextasdescribedinSection4.eof *
includedintheouterheader *
includesMIMEstructure ,Content
independentlyofwhetherS *
indicatorthatitisnottrustworthy *
informationcontainedtherein. *
insensitiveandcanbeeither *
insertionofpublickeys ,therootentityoftheprotectedmessageis
instead ,bywrappingitandprovidingcryptographicservicestothe
isitselfcoveredbytheprotectionmechanisms *
issuesaspreviouslydiscussed. *
issueshasonlyrecentlybeenexpressedintheIETFLAMPSWorking *
it. *
levelperspective ,specificallyDomainKeysIdentifiedMail
levelprotectbodypart *
librarieswidelyusedshallnotneedtobechangedtocomplywith *
maintained. *
makesusetheContent-Typeparameter *
materialortocitethemotherthanas *
meansthatthemessagenestedinside *
mechanismwillbechosen ,itshouldnotbelimitedtoS
mergedintothisdocument.SpecialthankstoitsauthorClaudio *
message *
mightlooklikethis. *
mixedContent-Typecontainingtheoriginalmessage *
moreoftheentitiesinvolvedinacommunicationassociation. *
normalmessageheaderfieldsintotheMIMEheadersectionofthetop *
notsupportanyHP *
oAddmoretextonMemoryHole *
oCorrectterminologyforHeader *
oDataMinimization ,whichincludesdatasparenessandhidingall
oDecideinwhichformlegacyHPrequirementsshouldremaininthis *
oEnhanceIntroductionandProblemStatementsections *
oHeaderField *
oHeaderProtection *
oHeaderSection *
oImprovedefinitionsinSection3.2 *
oInteroperabilitywith implementations
oMITMattacks *
oMan-in-the-middle *
oRephraseAppendixA.1.2 *
oReplace *
oResolvequestionregardingBccinAppendixA.2.1 *
oRewriteAppendixA.2.1 *
oShouldrequirementG3remain *
oUserinteraction *
oWriteAppendixA.3.2 *
odraft-ietf-lamps-header-protection-requirements-00 *
odraft-ietf-lamps-header-protection-requirements-01 *
ofaheaderfieldtodisplay............22 *
ofattacksonemail ,donotofferfullend
ofthemessage ,whichleavessignificantroomforattacksagainst
onlytheinnerheaderfieldvalueMUSTbedisplayed *
orderived. *
otherway *
otherwise-protectedmessages. *
pEpforemail definesafixedMIMEstructure
pEphasalsoimplementedtheabove *
parameters ,suchas
parametersetto *
part.SincetheMIMEbodypartheadersectionisitselfcoveredby *
particular ,Subject
particular ,Keywords,In
particulardowngradeattacks ,canbedetected.
particulardowngradeattacks ,aremitigatedtothegreatestextent
possible ,hasgrowninimportanceoverthepastseveralyears.
possible. *
prependedby *
privacy ,existingimplementationsshallnotrequiresubstantial
privacyinpEp ,forwhichreasontheapplicationofsignatures
protectionsofthemessagebody. *
protecttheinnerheadersection. *
providedhelpfulcommentsandsuggestionsforthisdocument *
provideheaderprotection.ThisentitySHOULDbepresentedasthe *
provisionsofBCP78andBCP79. *
publicationofthisdocument.Pleasereviewthesedocuments *
purposeful.pEpforemail ,eitherexpectstotransfermessagesin
receivingsideneedscertainguidelinesonhowtoprocessreceived *
recipients *
regardingheaderprotection. *
regardingtheimplementation.Althoughnot *
requirements ,thisisusefultobetterunderstandthem.Partsofthe
requirementsofheaderprotection. *
returnedinIMAPENVELOPEFETCHdataitem ,whichis
rfc822container arethusupdatedtoread
sectionof .
sensitive ,toMonday9amofthesameweek
separatelywithaBccheaderfieldcontainingonlytheaddressof *
sidefullysupportsHP *
signaturecalculationnorforencryption. *
someotherway ,forexamplewithaDKIMsignaturethatvalidates
spamprocessing. *
sparenessandhidingalltechnicallyconcealableinformationwhenever *
specificimplementations. *
suchas *
suchmessageswhichislessconfusing *
supportslegacyHPonly *
technicallyconcealableinformationwheneverpossible *
technologyisusedtoachieveHP. *
textinthisAppendixAwilllikelybemovedtotheupcoming *
thatall *
theTrustLegalProvisionsandareprovidedwithoutwarrantyas *
thefollowingintermediateinteractionsneedtobeconsideredas *
theinnerandtheouterheadersection. *
thenewmechanismforHP. *
theouterheadersectiononlycontains *
theprotectionmechanisms *
thepublickey *
therecipientitissentto *
thisdocument. *
thusmoresecure. *
thusnestedoncemoreintoanadditionalmultipart *
time.ItisinappropriatetouseInternet-Draftsasreference *
tobeincludedintheouterheadersection. *
tobeusedfordisplay *
top-levelmessage ,takingintoaccountheadersectionmerging
toplevel.Thisshouldalsoworkfortriple-wrappedmessages. *
toprotect *
totheseheaderfields. *
totheseheaderfields.Itisuptothereceivingclientto *
tothisdocument.CodeComponentsextractedfromthisdocumentmust *
toupdate .
truevalueMUSTNOTbeincludedintheouterheader.Ifthe *
unprotected *
usabilityandinteroperabilityincryptographically-protected *
usecases *
usedtoapplyHPto. *
usuallycontainstheBccunchangedfromtheoriginalmessage ,
value ,orcontainaclearindicationthattheoutervalueisnot
valueasintheinnerheaderfield ,or,iftheDatevalueisalso
verifywhetherthisrequirementappliesgenerallyorjustfor *
well *
wellforbackwardcompatibilitywithlegacyHPsystems ,suchas
whendisplayedtotheuser. *
whichdoesnotincludeaBccheaderfield *
wholeoriginalmessage.However ,forthepurposeofallowingthe
withaBccheaderfieldcontaininganindicationsuchas *
withoutencryptiontomessagesintransitisnotconsidered *
withoutthe *
work-in-progress. *
workingdocumentsasInternet-Drafts.ThelistofcurrentInternet- *
wrapper. *

inactive/ietf-lamps-hp-requirements/review/draft-ietf-lamps-header-protection-requirements-01-pre20191018.txt pypi

1.1.RequirementsLanguage *
1.1.RequirementsLanguage..................4 *
1.2.Terms *
1.2.Terms..........................4 *
1.Ifaheaderfieldisbeingencryptedbecauseitissensitive ,its
1.Introduction *
1.Introduction........................3 *
1.ThemessagesenttotherecipientaddresseslistedinToorCc *
1.Theouterheaderfieldsmightbetamperedwith ,soareceiving
14CastleMews *
2.1.Privacy *
2.1.Privacy.........................4 *
2.2.Security *
2.2.Security........................5 *
2.3.Usability *
2.3.Usability........................5 *
2.4.Interoperability *
2.4.Interoperability....................5 *
2.ProblemStatement *
2.ProblemStatement......................4 *
2.Themessage *
2.TheouterheadersectionSHOULDbeminimalinordertoavoid *
3.1.Interactions *
3.1.Interactions......................5 *
3.2.ProtectionLevels *
3.2.ProtectionLevels....................6 *
3.The *
3.Themessagestoredinthe *
3.UseCases *
3.UseCases..........................5 *
4.1.1.SendingSide *
4.1.1.SendingSide....................7 *
4.1.2.ReceivingSide *
4.1.2.ReceivingSide...................8 *
4.1.GeneralRequirements *
4.1.GeneralRequirements..................7 *
4.2.1.Sendingside *
4.2.1.Sendingside....................8 *
4.2.2.Receivingside *
4.2.2.Receivingside...................9 *
4.2.AdditionalRequirementsforBackward-CompatibilityWith *
4.2.AdditionalRequirementsforBackward-CompatibilityWithLegacy *
4.3.1.SendingSide *
4.3.1.SendingSide....................9 *
4.3.2.ReceivingSide *
4.3.2.ReceivingSide...................9 *
4.3.AdditionalRequirementsforBackward-Compatibilitywith *
4.3.AdditionalRequirementsforBackward-CompatibilitywithLegacy *
4.Requirements *
4.Requirements........................7 *
4rev1 *
5.SecurityConsiderations *
5.SecurityConsiderations...................9 *
6.PrivacyConsiderations *
6.PrivacyConsiderations...................10 *
7.IANAConsiderations *
7.IANAConsiderations.....................10 *
8.Acknowledgments *
8.Acknowledgments.......................10 *
9.1.NormativeReferences *
9.1.NormativeReferences..................10 *
9.2.InformativeReferences *
9.2.InformativeReferences.................11 *
9.References *
9.References.........................10 *
A.1.1.Option1 *
A.1.2.1.Content-TypeParameter *
A.1.2.Option2 *
A.1.3.Option2.1 *
A.1.4.1.Option1 *
A.1.4.2.Option2 *
A.1.4.3.Option2.1ProgressiveHeaderDisclosure *
A.1.4.Examples *
A.1.4.Examples......................14 *
A.1.OptionstoAchieveHeaderProtection *
A.1.OptionstoAchieveHeaderProtection..........12 *
A.2.1.CandidateHeaderFieldsforHeaderProtection *
A.2.1.CandidateHeaderFieldsforHeaderProtection....20 *
A.2.SendingSideConsiderations *
A.2.SendingSideConsiderations...............20 *
A.3.1.WhichHeaderFieldstoDisplaytoUser *
A.3.1.WhichHeaderFieldstoDisplaytoUser.......22 *
A.3.2.MailUserAgentAlgorithmfordecidingwhichversion *
A.3.2.MailUserAgentAlgorithmfordecidingwhichversionofaheader *
A.3.ReceivingSideConsiderations *
A.3.ReceivingSideConsiderations..............22 *
Abstract *
AlexeyMelnikov *
AppendixA.1.2.1 *
AppendixA.ImplementationConsiderations *
AppendixA.ImplementationConsiderations...........12 *
AppendixB.DocumentChangelog *
AppendixB.DocumentChangelog.................22 *
AppendixC.OpenIssues *
AppendixC.OpenIssues....................23 *
Arangeofprotocolsfortheprotectionofelectronicmail *
Astandardforend-to-endprotectionoftheemailheadersection *
AuthorizingUseofDomainsinEmail ,Version1
Authors *
B1 *
BR1 *
BS1 *
BS2 *
BS3 *
BernieHoeneisen *
Bodies *
Butnotethathavingkeyheaderfieldsduplicatedintheouter *
CH-8046Zuerich *
CertainimplementationsMAYdecidetosend *
ClientsUnawareofHeaderProtection *
Content-Transfer-Encoding *
Content-Type *
Content-Typeparameter *
Copyright *
CopyrightNotice *
DOI10.17487 *
Date *
DavidWilsoncameupwiththeideaofdefininganewContent-Type *
Disclosure *
Email *
EmailHeaders *
Essentialpartsof havebeen
Examplesinsubsequentsectionsassumethatanemailclientistrying *
Expires *
Extensions *
FYI36 ,RFC4949,DOI10.17487
Fora *
Forbackwardcompatibilityoflegacyclients-unawareofanyHP- *
From *
G1 *
G2 *
G3 *
G4 *
GR1 *
GR2 *
GR3 *
GS1 *
GS2 *
GS3 *
GS4 *
Hampton ,MiddlesexTW122NP
HeaderProtectionSystems *
Ifyes ,considerimprove
Inordertoprotectouter ,non
Instructionsin describinghowtoprotecttheEmailmessage
Intendedstatus *
Internet-DraftHeaderProtectionrequirementsOctober2019 *
Internet-DraftIsodeLtd *
Internet-Draftsaredraftdocumentsvalidforamaximumofsixmonths *
Internet-DraftsareworkingdocumentsoftheInternetEngineering *
Inthefollowingalistofrequirementsthatneedtobeaddressed *
Inthefollowingalistofthegenericusecasesthatneedtobe *
InthefollowingasetofOptionstoachieveEmailHeaderProtection. *
Inthefollowingasetofchallengestobeaddressed *
Inthiscase ,the
IsodeLtd *
ItisexpectedthattheIETFLAMPSWGchoosesanoptiontoupdate *
LS1 *
LS2 *
LSR1 *
LSS1 *
LSS2 *
LegacyClientsUnawareofHeaderProtection.......8 *
LegacyHeaderProtectionSystems *
Luck ,C.,
Luck.ForfurtherAcknowledgments ,pleaserefertoAcknowledgments
MIME-Version *
MIMEentityhasaContent-Typeofmessage *
MIMEheaderfields *
MIMEstructure ,Content
MMHS-Primary-Precedence *
Marques ,H.,
Melnikov *
MemoryHoleapproachworksbycopyingthenormalmessageheader *
Message-ID *
MessageAuthentication ,Reporting,andConformance
MessageSpecification *
Messagescontainingacryptographicsignature ,whicharealso
Messagescontainingacryptographicsignature ,butwhichno
MessagescontainingatleastonerecipientaddressintheBccheader *
Messagesthatencryptionisappliedto ,whichdonotcontaina
Moreinformationonprogressiveheaderdisclosurecanbefoundin *
MultipurposeInternetMailExtensions *
NetworkWorkingGroupA.Melnikov *
Nomechanismforheaderprotection *
Note *
Notethatrecommendationslistedabovetypicallyonlyapplytonon *
Notethattheaboverecommendationscanalsonegativelyaffectanti- *
Notethatthisvariantmayhaveadversesideeffectsregarding *
October18 ,2019
October2018. *
OneofthegoalsofthisdocumentistospecifyUIfordisplaying *
Phone *
PrivacyandsecurityissueswithemailheaderprotectioninS *
ProblemStatementandRequirementsforHeaderProtection *
Protocols *
ProvisionsRelatingtoIETFDocuments *
RFC6376 ,DOI10.17487
RegardingtheBccheaderfieldthereshouldbenodifferencebetween *
RequirementLevels *
SHOULDNOTbeincludedintheouterheader *
SHOULDeitherbeidenticaltotheinner *
Section3.1 *
Section3.2 *
SendingandreceivingsideSHOULDimplement *
Severalvariantsofend-to-endprotectionfortheemailheader *
SomeLAMPSWGparticipantsexpressedtheopinionthatwhatever *
StatusofThisMemo *
Subject *
Switzerland *
TableofContents *
TaskForce *
Thayer ,
TheLAMPSchartercontainsthefollowingWorkItem *
Theauthorswouldliketothankthefollowingpeoplewhohave *
ThecurrentpEpproposalisforPGP *
Thedocumentisnotdefiningnewprotocol ,soitdoesn
Thefollowingexampledemonstrateshowheadersectionandpayloadof *
Thefollowingintermediateusecasesmayneedtobeconsideredas *
Thefollowingprotectionlevelsneedtobeconsidered *
Thefollowingtermsaredefinedforthescopeofthisdocument *
Thekeywords *
ThemaindifferencecomparedtoOption2isanadditionalmultipart *
ThemaininteractioncaseforHeaderProtection *
TheneedformeansofDataMinimization ,whichincludesdata
ThepEpmessageformatisequivalenttotheS *
ThisAppendixAcontainsadditionalinformationandconsiderations *
ThisInternet-Draftissubmittedinfullconformancewiththe *
ThisInternet-DraftwillexpireonApril20 ,2020.
ThisdocumentdefinesanewContent-Typeheaderfieldparameter *
Thisdocumentdescribestheproblemstatement *
Thisdocumentdescribestheproblemstatement ,genericusecases,and
ThisdocumentissubjecttoBCP78andtheIETFTrust *
ThisdocumentrequestsnoactionfromIANA. *
ThisdocumenttalksaboutUIconsiderations ,includingsecurity
ThisisamultipartmessageinMIMEformat. *
ThisisanimportantmessagethatIdon *
ThisoptionissimilartoOption2 *
Thissectionoutlineshowthenew *
To *
UK *
UcomStandardsTrackSolutionsGmbH *
Updatethespecificationforthecryptographicprotectionofemail *
WhenanS *
WhendisplayingS *
WhengeneratingS *
Wilson ,SteveKille,WeiChuang,andRobertWilliams
Withoutmessageheaderprotectionthecorrespondingsignedmessage *
Wrappingwithmessage *
X-Mailer *
aBccheaderfieldoraBccheaderfieldcontaininganindication *
addressedformessageswithHeaderProtection *
addressees *
alltechnicallyconcealableinformationwheneverpossible *
alsoapplicabletoPGP *
and *
andReceivingsidesSHOULDimplement *
andadjustedtotheaboveS *
andaimtominimizetheimplementationefforttoincludesupport *
andhowheadersectionwrappingworks *
andistrusted. *
andmaybeupdated ,replaced,orobsoletedbyotherdocumentsatany
andselectivelymodifiescommunicateddatatomasqueradeasoneor *
andthenprependingthemwith *
andwithenclosedsignatureandnecessarypublickeyssothatreplies *
applyindependentlyofwhetherS *
aprotectbodypartmightlooklike.Forexample ,thiswillbethe
arefurtherexplainedinSection3.2. *
aretobetreated. *
asforillustrativepurpose.Specificexamplescanbefoundin *
atleastfor *
basedMessageAuthentication ,Reporting,andConformance
beforepublication. *
being *
bodypart ,extractheaderfieldsfromitandpropagatethemtothe
by *
canbeimmediatelyupgradedtoencryptedmessages. *
carefully ,astheydescribeyourrightsandrestrictionswithrespect
challengeandsomebestpracticesarecollected.Inanycase ,the
changesintheexistingcodebase.InparticularalsoMIME *
cleartextwithoutsignatureorencryption ,ortransferthemencrypted
clientSHOULDignorethem ,unlesstheyareprotectedinsome
clientsthatcan *
conflictinginformationbetweentheprotectedandunprotected *
conflictwithanynewsolutionforHPatallorwhether *
considerations ,whenprocessingmessagesprotectingheaderfields.
containinganindicationsuchas *
containthetruevalue *
copied ,butalsothecontent.
correspondingoutervaluemustbeignored *
cryptographically-protectedelectronicmailprotectonlythebody *
cryptographicsignature. *
decidehowtopresentthis *
degree *
dependingonthecircumstancesandcustomerrequirements.Sending *
describedintheSimplifiedBSDLicense. *
designatedaslegacyHP *
destinationheaderfieldismandatoryasper .
differ ,theycansimplybereplacedwiththeirprotectedversions
disclosureofconfidentialinformation.Itisrecommendedthat *
document *
documentaretobeinterpretedasdescribedin .
documentauthors.Allrightsreserved. *
doesnotsupportanyHP *
donotsupportS *
draft-ietf-lamps-header-protection-requirements-01 *
easilyimplementable.Unlessneededformaximizingprotectionand *
electronicmail.Mostcurrentimplementationsof *
emailheaderssectionorselectedheaderfields *
emails. *
encapsulatedandforwardedemails. *
encapsulatedemailsusingnewHPmechanism. *
encrypted. *
encryptedpayloadoftheapplication *
encryption *
encryptionisappliedto. *
encryptiontoprotectheaderfields *
ensuringheaderprotection ,inthatthewholemessageisprotected
exist ,whichallowtoassesstheauthenticityandintegrityofthe
existsforS *
field ,whichdependsontheimplementation
fieldmayappearinuptothreedifferentvariants *
fieldparametercouldbedefined *
fields *
fieldsintotheMIMEheadersectionofthetoplevelprotectedbody *
fieldsshouldbeomittedandreplacedwith *
fieldtodisplay *
finalsolutionistobedeterminedbytheIETFLAMPSWG. *
firstbodypartofamultipart *
forexistingsolutions. *
foritsinnermostmessagestructure.Securitycomesjustnextafter *
formofactivewiretappingattackinwhichtheattackerintercepts *
forwarded =no
forwardedemails ,legacyencapsulatedemails,and
frequentlyusedbyIMAPclientsinordertoavoidparsingmessage *
fullysupportsHP *
global *
guessed. *
havebeenidentifiedforsometime.However ,thedesiretofixthese
header. *
headerfieldismandatoryaccordingto ,astubvalue
headerfieldisonlypresentintheouterheader ,itMAYbe
headerfieldparametertodistinguishforwardedmessagesfrominner *
headerfieldprotectionconstructs. *
headerfields ,whichmustnotincludetheBccheaderfield
headerfields. *
headerfields.Andinthecasethatthe *
headerfields.Thiswouldmeanthatallheaderfieldsaresigned. *
headerisconvenientformanymessagestores *
headers-bothforsignaturesandencryption-toimprovethe *
headersection ,bywrappingthemessageinsideamessage
headersectionandarenotcapableofprovidingprivacyforthe *
i.e.withallrecipientaddresses. *
ignored *
implementationdocument. *
implementationsituationwithrespecttoprivacy ,security,
includeSimplifiedBSDLicensetextasdescribedinSection4.eof *
independentlyofwhetherS *
indicatorthatitisnottrustworthy *
informationcontainedtherein. *
insensitiveandcanbeeither *
insertionofpublickeys ,therootentityoftheprotectedmessageis
instead ,bywrappingitandprovidingcryptographicservicestothe
isitselfcoveredbytheprotectionmechanisms *
issuehasbeenexpressedintheIETFLAMPSWorkingGrouponly *
issuesaspreviouslydiscussed. *
it. *
levelperspective ,specificallyDomainKeysIdentifiedMail
levelprotectbodypart *
librarieswidelyusedshallnotneedtobechangedtocomplywith *
maintained. *
makesusetheContent-Typeparameter *
materialortocitethemotherthanas *
meansthatthemessagenestedinside *
mechanismwillbechosen ,itshouldnotbelimitedtoS
mergedintothisdocument.SpecialthankstoitsauthorClaudio *
message *
mightlooklikethis. *
mixedContent-Typecontainingtheoriginalmessage *
moreoftheentitiesinvolvedinacommunicationassociation. *
mustnotbeincludedintheouterheader *
neitherforsignaturecalculationnorforencryption. *
newsecurityconcernsnotalreadycoveredbyS *
normalmessageheaderfieldsintotheMIMEheadersectionofthetop *
notsupportanyHP *
oAddmoretextonMemoryHole *
oCorrectterminologyforHeader *
oDataMinimization ,whichincludesdatasparenessandthehidingof
oDecideinwhichformlegacyHPrequirementsshouldremaininthis *
oEnhanceIntroductionandProblemStatementsections *
oHeaderField *
oHeaderProtection *
oHeaderSection *
oImprovedefinitionsinSection3.2 *
oInteroperabilitywith implementations
oMITMattacks *
oMan-in-the-middle *
oRephraseAppendixA.1.2 *
oResolvequestionregardingBccinAppendixA.2.1 *
oRewriteAppendixA.2.1 *
oShouldrequirementG3remain *
oUserinteraction *
oWriteAppendixA.3.2 *
odraft-ietf-lamps-header-protection-requirements-00 *
odraft-ietf-lamps-header-protection-requirements-01 *
ofaheaderfieldtodisplay............22 *
ofattacksonemail ,donotofferfullend
ofthemessage ,whichleavessignificantroomforattacksagainst
onlytheinnerheaderfieldvalueMUSTbedisplayed *
orguessed. *
otherway *
otherwise-protectedmessages. *
pEpforemail definesafixedMIMEstructure
pEphasalsoimplementedtheabove *
parameters ,suchas
parametersetto *
part.SincetheMIMEbodypartheadersectionisitselfcoveredby *
particular ,Subject
particular ,Keywords,In
particulardowngradeattacks ,aremitigatedasgoodaspossible.
particulardowngradeattacks ,canbedetected.
prependedby *
privacy ,existingimplementationsshallnotrequiresubstantial
privacyasrecipientsintheBccheaderfieldmayseeall *
privacyinpEp ,forwhichreasontheapplicationofsignatures
protectionsofthemessagebody. *
protecttheinnerheadersection. *
providedhelpfulcommentsandsuggestionsforthisdocument *
provideheaderprotection.ThisentitySHOULDbepresentedasthe *
provisionsofBCP78andBCP79. *
publicationofthisdocument.Pleasereviewthesedocuments *
purposeful.pEpforemail ,eitherexpectstotransfermessagesin
receivingsideneedscertainguidelinesonhowtoprocessreceived *
recently.TheexistingS *
recipientaddresseslistedintheBccheaderfield. *
recipients *
regardingheaderprotection. *
regardingtheimplementation.Althoughnot *
requirements ,thisisusefultobetterunderstandthem.Partsofthe
requirements. *
returnedinIMAPENVELOPEFETCHdataitem ,whichis
rfc822container arethusupdatedtoread
sectionof .
sectionsareknowntobeimplemented ,howeversofarnotmanyemail
sectionsforsignaturesandencryption *
secure. *
sensitive ,toMonday9amofthesameweek
separatelywithaBccheaderfieldcontainingonlytheaddressof *
separatelywithoutaBccheaderfieldoraBccheaderfield *
sidefullysupportsHP *
someotherway ,forexamplewithaDKIMsignaturethatvalidates
spamprocessing. *
sparenessandthehidingofalltechnicallyconcealableinformation *
specificimplementations. *
suchas *
suchmessageswhichislessconfusing *
supportslegacyHPonly *
systemsarehavebeendiscoveredtoimplementthisfeature. *
technologyisusedtoachieveHP. *
textinthisAppendixAwilllikelybemovedtotheupcoming *
thatall *
theTrustLegalProvisionsandareprovidedwithoutwarrantyas *
thefollowingintermediateinteractionsneedtobeconsideredas *
theinnerandtheouterheadersection. *
thenewmechanismforHP. *
theouterheadersectiononlycontains *
theprotectionmechanisms *
thepublickey *
therecipientitissentto. *
thisdocument. *
thusnestedoncemoreintoanadditionalmultipart *
time.ItisinappropriatetouseInternet-Draftsasreference *
tobeincludedintheouterheadersection. *
tobeusedfordisplay *
top-levelmessage ,takingintoaccountheadersectionmerging
toplevel.Thisshouldalsoworkfortriple-wrappedmessages. *
toprotect *
totheseheaderfields. *
totheseheaderfields.Itisuptothereceivingclientto *
tothisdocument.CodeComponentsextractedfromthisdocumentmust *
truevalueMUSTNOTbeincludedintheouterheader.Ifthe *
unprotected *
usabilityandinteroperabilityincryptographically-protected *
usecases *
usedtoapplyHPto. *
usuallycontainstheBccunchangedfromtheoriginalmessage ,
value ,orcontainaclearindicationthattheoutervalueisnot
valueasintheinnerheaderfield ,or,iftheDatevalueisalso
verifywhetherthisrequirementappliesgenerallyorjustfor *
well *
wellforbackwardcompatibilitywithlegacyHPsystems ,suchas
whendisplayedtotheuser. *
wheneverpossible ,hasgrowninimportanceoverthepastyears.
wholeoriginalmessage.However ,forthepurposeofallowingthe
with *
withoutencryptiontomessagesintransitisnotconsidered *
withoutthe *
work-in-progress. *
workingdocumentsasInternet-Drafts.ThelistofcurrentInternet- *
wrapper. *

inactive/ietf-lamps-hp-requirements/review/draft-ietf-lamps-header-protection-requirements-01-pre20191018_krb.txt pypi

1.1.RequirementsLanguage *
1.1.RequirementsLanguage..................4 *
1.2.Terms *
1.2.Terms..........................4 *
1.Ifaheaderfieldisbeingencryptedbecauseitissensitive ,its
1.Introduction *
1.Introduction........................3 *
1.ThemessagesenttotherecipientaddresseslistedinToorCc *
1.Theouterheaderfieldsmightbetamperedwith ,soareceiving
14CastleMews *
2.1.Privacy *
2.1.Privacy.........................4 *
2.2.Security *
2.2.Security........................5 *
2.3.Usability *
2.3.Usability........................5 *
2.4.Interoperability *
2.4.Interoperability....................5 *
2.ProblemStatement *
2.ProblemStatement......................4 *
2.Themessage *
2.TheouterheadersectionSHOULDbeminimalinordertoavoid *
3.1.Interactions *
3.1.Interactions......................5 *
3.2.ProtectionLevels *
3.2.ProtectionLevels....................6 *
3.The *
3.Themessagestoredinthe *
3.UseCases *
3.UseCases..........................5 *
4.1.1.SendingSide *
4.1.1.SendingSide....................7 *
4.1.2.ReceivingSide *
4.1.2.ReceivingSide...................8 *
4.1.GeneralRequirements *
4.1.GeneralRequirements..................7 *
4.2.1.Sendingside *
4.2.1.Sendingside....................8 *
4.2.2.Receivingside *
4.2.2.Receivingside...................9 *
4.2.AdditionalRequirementsforBackward-CompatibilityWith *
4.2.AdditionalRequirementsforBackward-CompatibilityWithLegacy *
4.3.1.SendingSide *
4.3.1.SendingSide....................9 *
4.3.2.ReceivingSide *
4.3.2.ReceivingSide...................9 *
4.3.AdditionalRequirementsforBackward-Compatibilitywith *
4.3.AdditionalRequirementsforBackward-CompatibilitywithLegacy *
4.Requirements *
4.Requirements........................7 *
4rev1 *
5.SecurityConsiderations *
5.SecurityConsiderations...................9 *
6.PrivacyConsiderations *
6.PrivacyConsiderations...................10 *
7.IANAConsiderations *
7.IANAConsiderations.....................10 *
8.Acknowledgments *
8.Acknowledgments.......................10 *
9.1.NormativeReferences *
9.1.NormativeReferences..................10 *
9.2.InformativeReferences *
9.2.InformativeReferences.................11 *
9.References *
9.References.........................10 *
A.1.1.Option1 *
A.1.2.1.Content-TypeParameter *
A.1.2.Option2 *
A.1.3.Option2.1 *
A.1.4.1.Option1 *
A.1.4.2.Option2 *
A.1.4.3.Option2.1ProgressiveHeaderDisclosure *
A.1.4.Examples *
A.1.4.Examples......................14 *
A.1.OptionstoAchieveHeaderProtection *
A.1.OptionstoAchieveHeaderProtection..........12 *
A.2.1.CandidateHeaderFieldsforHeaderProtection *
A.2.1.CandidateHeaderFieldsforHeaderProtection....20 *
A.2.SendingSideConsiderations *
A.2.SendingSideConsiderations...............20 *
A.3.1.WhichHeaderFieldstoDisplaytoUser *
A.3.1.WhichHeaderFieldstoDisplaytoUser.......22 *
A.3.2.MailUserAgentAlgorithmfordecidingwhichversion *
A.3.2.MailUserAgentAlgorithmfordecidingwhichversionofaheader *
A.3.ReceivingSideConsiderations *
A.3.ReceivingSideConsiderations..............22 *
Abstract *
AlexeyMelnikov *
Also ,wecapitalizedProtectionLevelshere,whichisinconsistentwithpriorusesofthephrase.
AppendixA.1.2.1 *
AppendixA.ImplementationConsiderations *
AppendixA.ImplementationConsiderations...........12 *
AppendixB.DocumentChangelog *
AppendixB.DocumentChangelog.................22 *
AppendixC.OpenIssues *
AppendixC.OpenIssues....................23 *
Arangeofprotocolsfortheprotectionofelectronicmail *
Astandardforend-to-endprotectionoftheemailheadersection *
AuthorizingUseofDomainsinEmail ,Version1
Authors *
B1 *
BR1 *
BS1 *
BS2 *
BS3 *
BernieHoeneisen *
Bodies *
Butnotethathavingkeyheaderfieldsduplicatedintheouter *
CH-8046Zuerich *
CertainimplementationsMAYdecidetosend *
ClientsUnawareofHeaderProtection *
Content-Transfer-Encoding *
Content-Type *
Content-Typeparameter *
Copyright *
CopyrightNotice *
DOI10.17487 *
Date *
DavidWilsoncameupwiththeideaofdefininganewContent-Type *
Disclosure *
Doyoumeanthatthechosenformatshouldcoverallprotectionlevels *
Email *
EmailHeaders *
Essentialpartsof havebeen
Examplesinsubsequentsectionsassumethatanemailclientistrying *
Expires *
Extensions *
FYI36 ,RFC4949,DOI10.17487
Fora *
Forbackwardcompatibilityoflegacyclients-unawareofanyHP- *
From *
G1 *
G2 *
G3 *
G4 *
GR1 *
GR2 *
GR3 *
GS1 *
GS2 *
GS3 *
GS4 *
Hampton ,MiddlesexTW122NP
HeaderProtectionSystems *
Ifyes ,considerimprove
Inordertoprotectouter ,non
Instructionsin describinghowtoprotecttheEmailmessage
Intendedstatus *
Internet-DraftHeaderProtectionrequirementsOctober2019 *
Internet-DraftIsodeLtd *
Internet-Draftsaredraftdocumentsvalidforamaximumofsixmonths *
Internet-DraftsareworkingdocumentsoftheInternetEngineering *
Inthefollowingalistofrequirementsthatneedtobeaddressed *
Inthefollowingalistofthegenericusecasesthatneedtobe *
InthefollowingasetofOptionstoachieveEmailHeaderProtection. *
Inthefollowingasetofchallengestobeaddressed *
Inthiscase ,the
IsodeLtd *
ItisexpectedthattheIETFLAMPSWGchoosesanoptiontoupdate *
LS1 *
LS2 *
LSR1 *
LSS1 *
LSS2 *
LegacyClientsUnawareofHeaderProtection.......8 *
LegacyHeaderProtectionSystems *
Luck ,C.,
Luck.ForfurtherAcknowledgments ,pleaserefertoAcknowledgments
MIME-Version *
MIMEentityhasaContent-Typeofmessage *
MIMEheaderfields *
MIMEstructure ,Content
MMHS-Primary-Precedence *
Marques ,H.,
Melnikov *
MemoryHoleapproachworksbycopyingthenormalmessageheader *
Message-ID *
MessageAuthentication ,Reporting,andConformance
MessageSpecification *
Messagescontainingacryptographicsignature ,whicharealso
Messagescontainingacryptographicsignature ,butwhichno
MessagescontainingatleastonerecipientaddressintheBccheader *
Messagesthatencryptionisappliedto ,whichdonotcontaina
Moreinformationonprogressiveheaderdisclosurecanbefoundin *
MultipurposeInternetMailExtensions *
NetworkWorkingGroupA.Melnikov *
Newsentencefromtheremainder.Suggest *
Nomechanismforheaderprotection *
Note *
Notethatrecommendationslistedabovetypicallyonlyapplytonon *
Notethattheaboverecommendationscanalsonegativelyaffectanti- *
Notethatthisvariantmayhaveadversesideeffectsregarding *
October18 ,2019
October2018. *
OneofthegoalsofthisdocumentistospecifyUIfordisplaying *
Phone *
PrivacyandsecurityissueswithemailheaderprotectioninS *
ProblemStatementandRequirementsforHeaderProtection *
Protocols *
ProvisionsRelatingtoIETFDocuments *
RFC6376 ,DOI10.17487
RegardingtheBccheaderfieldthereshouldbenodifferencebetween *
RequirementLevels *
SHOULDNOTbeincludedintheouterheader *
SHOULDeitherbeidenticaltotheinner *
Section3.1 *
Section3.2 *
SendingandreceivingsideSHOULDimplement *
Severalvariantsofend-to-endprotectionfortheemailheader *
SomeLAMPSWGparticipantsexpressedtheopinionthatwhatever *
StatusofThisMemo *
Subject *
Switzerland *
TableofContents *
TaskForce *
Thayer ,
TheLAMPSchartercontainsthefollowingWorkItem *
Theauthorswouldliketothankthefollowingpeoplewhohave *
ThecurrentpEpproposalisforPGP *
Thedocumentisnotdefiningnewprotocol ,soitdoesn
Thefollowingexampledemonstrateshowheadersectionandpayloadof *
Thefollowingintermediateusecasesmayneedtobeconsideredas *
Thefollowingprotectionlevelsneedtobeconsidered *
Thefollowingtermsaredefinedforthescopeofthisdocument *
Thekeywords *
ThemaindifferencecomparedtoOption2isanadditionalmultipart *
ThemaininteractioncaseforHeaderProtection *
TheneedformeansofDataMinimization ,whichincludesdata
ThepEpmessageformatisequivalenttotheS *
ThisAppendixAcontainsadditionalinformationandconsiderations *
ThisInternet-Draftissubmittedinfullconformancewiththe *
ThisInternet-DraftwillexpireonApril20 ,2020.
ThisdocumentdefinesanewContent-Typeheaderfieldparameter *
Thisdocumentdescribestheproblemstatement *
Thisdocumentdescribestheproblemstatement ,genericusecases,and
ThisdocumentissubjecttoBCP78andtheIETFTrust *
ThisdocumentrequestsnoactionfromIANA. *
ThisdocumenttalksaboutUIconsiderations ,includingsecurity
ThisisamultipartmessageinMIMEformat. *
ThisisanimportantmessagethatIdon *
ThisoptionissimilartoOption2 *
Thissectionoutlineshowthenew *
To *
UK *
UcomStandardsTrackSolutionsGmbH *
Updatethespecificationforthecryptographicprotectionofemail *
WhenanS *
WhendisplayingS *
WhengeneratingS *
Wilson ,SteveKille,WeiChuang,andRobertWilliams
Withoutmessageheaderprotectionthecorrespondingsignedmessage *
Wrappingwithmessage *
X-Mailer *
aBccheaderfieldoraBccheaderfieldcontaininganindication *
addressedformessageswithHeaderProtection *
addressees *
alltechnicallyconcealableinformationwheneverpossible *
alsoapplicabletoPGP *
and *
andReceivingsidesSHOULDimplement *
andadjustedtotheaboveS *
andaimtominimizetheimplementationefforttoincludesupport *
andhowheadersectionwrappingworks *
andistrusted. *
andmaybeupdated ,replaced,orobsoletedbyotherdocumentsatany
andselectivelymodifiescommunicateddatatomasqueradeasoneor *
andthenprependingthemwith *
andwithenclosedsignatureandnecessarypublickeyssothatreplies *
applyindependentlyofwhetherS *
aprotectbodypartmightlooklike.Forexample ,thiswillbethe
arefurtherexplainedinSection3.2. *
aretobetreated. *
asforillustrativepurpose.Specificexamplescanbefoundin *
atleastfor *
basedMessageAuthentication ,Reporting,andConformance
beforepublication. *
being *
bodypart ,extractheaderfieldsfromitandpropagatethemtothe
by *
canbeimmediatelyupgradedtoencryptedmessages. *
carefully ,astheydescribeyourrightsandrestrictionswithrespect
challengeandsomebestpracticesarecollected.Inanycase ,the
changesintheexistingcodebase.InparticularalsoMIME *
cleartextwithoutsignatureorencryption ,ortransferthemencrypted
clientSHOULDignorethem ,unlesstheyareprotectedinsome
clientsthatcan *
conflictinginformationbetweentheprotectedandunprotected *
conflictwithanynewsolutionforHPatallorwhether *
considerations ,whenprocessingmessagesprotectingheaderfields.
containinganindicationsuchas *
containthetruevalue *
copied ,butalsothecontent.
correspondingoutervaluemustbeignored *
cryptographically-protectedelectronicmailprotectonlythebody *
cryptographicsignature. *
decidehowtopresentthis *
degree *
dependingonthecircumstancesandcustomerrequirements.Sending *
describedintheSimplifiedBSDLicense. *
designatedaslegacyHP *
destinationheaderfieldismandatoryasper .
differ ,theycansimplybereplacedwiththeirprotectedversions
disclosureofconfidentialinformation.Itisrecommendedthat *
document *
documentaretobeinterpretedasdescribedin .
documentauthors.Allrightsreserved. *
doesnotsupportanyHP *
donotsupportS *
draft-ietf-lamps-header-protection-requirements-01 *
easilyimplementable.Unlessneededformaximizingprotectionand *
electronicmail.Mostcurrentimplementationsof *
emailheaderssectionorselectedheaderfields *
emails. *
encapsulatedandforwardedemails. *
encapsulatedemailsusingnewHPmechanism. *
encrypted. *
encryptedpayloadoftheapplication *
encryption *
encryptionisappliedto. *
encryptiontoprotectheaderfields *
ensuringheaderprotection ,inthatthewholemessageisprotected
exist ,whichallowtoassesstheauthenticityandintegrityofthe
existsforS *
field ,whichdependsontheimplementation
fieldmayappearinuptothreedifferentvariants *
fieldparametercouldbedefined *
fields *
fieldsintotheMIMEheadersectionofthetoplevelprotectedbody *
fieldsshouldbeomittedandreplacedwith *
fieldtodisplay *
finalsolutionistobedeterminedbytheIETFLAMPSWG. *
firstbodypartofamultipart *
forexistingsolutions. *
foritsinnermostmessagestructure.Securitycomesjustnextafter *
formofactivewiretappingattackinwhichtheattackerintercepts *
forwarded =no
forwardedemails ,legacyencapsulatedemails,and
frequentlyusedbyIMAPclientsinordertoavoidparsingmessage *
fullysupportsHP *
global *
guessed. *
havebeenidentifiedforsometime.However ,thedesiretofixthese
header. *
headerfieldismandatoryaccordingto ,astubvalue
headerfieldisonlypresentintheouterheader ,itMAYbe
headerfieldparametertodistinguishforwardedmessagesfrominner *
headerfieldprotectionconstructs. *
headerfields ,whichmustnotincludetheBccheaderfield
headerfields. *
headerfields.Andinthecasethatthe *
headerfields.Thiswouldmeanthatallheaderfieldsaresigned. *
headerisconvenientformanymessagestores *
headers-bothforsignaturesandencryption-toimprovethe *
headersection ,bywrappingthemessageinsideamessage
headersectionandarenotcapableofprovidingprivacyforthe *
howtohandleissuessurroundingfuturemaintenancefortheselegacysystems ,willbedecidedbytheLAMPSWG.
i.e.withallrecipientaddresses. *
ignored *
implementationdocument. *
implementationsituationwithrespecttoprivacy ,security,
includeSimplifiedBSDLicensetextasdescribedinSection4.eof *
independentlyofwhetherS *
indicatorthatitisnottrustworthy *
informationcontainedtherein. *
insensitiveandcanbeeither *
insertionofpublickeys ,therootentityoftheprotectedmessageis
instead ,bywrappingitandprovidingcryptographicservicestothe
isitselfcoveredbytheprotectionmechanisms *
issuehasbeenexpressedintheIETFLAMPSWorkingGrouponly *
issuesaspreviouslydiscussed. *
it. *
levelperspective ,specificallyDomainKeysIdentifiedMail
levelprotectbodypart *
librarieswidelyusedshallnotneedtobechangedtocomplywith *
maintained. *
makesusetheContent-Typeparameter *
materialortocitethemotherthanas *
meansthatthemessagenestedinside *
mechanismwillbechosen ,itshouldnotbelimitedtoS
mergedintothisdocument.SpecialthankstoitsauthorClaudio *
message *
mightlooklikethis. *
mixedContent-Typecontainingtheoriginalmessage *
moreoftheentitiesinvolvedinacommunicationassociation. *
mustnotbeincludedintheouterheader *
neitherforsignaturecalculationnorforencryption. *
newsecurityconcernsnotalreadycoveredbyS *
normalmessageheaderfieldsintotheMIMEheadersectionofthetop *
notsupportanyHP *
oAddmoretextonMemoryHole *
oCorrectterminologyforHeader *
oDataMinimization ,whichincludesdatasparenessandthehidingof
oDecideinwhichformlegacyHPrequirementsshouldremaininthis *
oEnhanceIntroductionandProblemStatementsections *
oHeaderField *
oHeaderProtection *
oHeaderSection *
oImprovedefinitionsinSection3.2 *
oInteroperabilitywith implementations
oMITMattacks *
oMan-in-the-middle *
oRephraseAppendixA.1.2 *
oResolvequestionregardingBccinAppendixA.2.1 *
oRewriteAppendixA.2.1 *
oShouldrequirementG3remain *
oUserinteraction *
oWriteAppendixA.3.2 *
odraft-ietf-lamps-header-protection-requirements-00 *
odraft-ietf-lamps-header-protection-requirements-01 *
ofaheaderfieldtodisplay............22 *
ofattacksonemail ,donotofferfullend
ofthemessage ,whichleavessignificantroomforattacksagainst
onlytheinnerheaderfieldvalueMUSTbedisplayed *
orguessed. *
orthatmultipleformatscanexist ,butatleastoneofthemneedstobeinclusiveofallthelevels
otherway *
otherwise-protectedmessages. *
pEpforemail definesafixedMIMEstructure
pEphasalsoimplementedtheabove *
parameters ,suchas
parametersetto *
part.SincetheMIMEbodypartheadersectionisitselfcoveredby *
particular ,Keywords,In
particular ,Subject
particulardowngradeattacks ,canbedetected.
particulardowngradeattacks ,aremitigatedasgoodaspossible.
prependedby *
privacy ,existingimplementationsshallnotrequiresubstantial
privacyasrecipientsintheBccheaderfieldmayseeall *
privacyinpEp ,forwhichreasontheapplicationofsignatures
protectionsofthemessagebody. *
protecttheinnerheadersection. *
providedhelpfulcommentsandsuggestionsforthisdocument *
provideheaderprotection.ThisentitySHOULDbepresentedasthe *
provisionsofBCP78andBCP79. *
publicationofthisdocument.Pleasereviewthesedocuments *
purposeful.pEpforemail ,eitherexpectstotransfermessagesin
receivingsideneedscertainguidelinesonhowtoprocessreceived *
recently.TheexistingS *
recipientaddresseslistedintheBccheaderfield. *
recipients *
regardingheaderprotection. *
regardingtheimplementation.Althoughnot *
requirements ,thisisusefultobetterunderstandthem.Partsofthe
requirements. *
returnedinIMAPENVELOPEFETCHdataitem ,whichis
rfc822container arethusupdatedtoread
sectionof .
sectionsareknowntobeimplemented ,howeversofarnotmanyemail
sectionsforsignaturesandencryption *
secure. *
sensitive ,toMonday9amofthesameweek
separatelywithaBccheaderfieldcontainingonlytheaddressof *
separatelywithoutaBccheaderfieldoraBccheaderfield *
sidefullysupportsHP *
someotherway ,forexamplewithaDKIMsignaturethatvalidates
spamprocessing. *
sparenessandthehidingofalltechnicallyconcealableinformation *
specificimplementations. *
suchas *
suchmessageswhichislessconfusing *
supportslegacyHPonly *
systemsarehavebeendiscoveredtoimplementthisfeature. *
technologyisusedtoachieveHP. *
textinthisAppendixAwilllikelybemovedtotheupcoming *
thatall *
theTrustLegalProvisionsandareprovidedwithoutwarrantyas *
thefollowingintermediateinteractionsneedtobeconsideredas *
theinnerandtheouterheadersection. *
thenewmechanismforHP. *
theouterheadersectiononlycontains *
theprotectionmechanisms *
thepublickey *
therecipientitissentto. *
thisdocument. *
thusnestedoncemoreintoanadditionalmultipart *
time.ItisinappropriatetouseInternet-Draftsasreference *
tobeincludedintheouterheadersection. *
tobeusedfordisplay *
top-levelmessage ,takingintoaccountheadersectionmerging
toplevel.Thisshouldalsoworkfortriple-wrappedmessages. *
toprotect *
totheseheaderfields. *
totheseheaderfields.Itisuptothereceivingclientto *
tothisdocument.CodeComponentsextractedfromthisdocumentmust *
truevalueMUSTNOTbeincludedintheouterheader.Ifthe *
unprotected *
usabilityandinteroperabilityincryptographically-protected *
usecases *
usedtoapplyHPto. *
usuallycontainstheBccunchangedfromtheoriginalmessage ,
value ,orcontainaclearindicationthattheoutervalueisnot
valueasintheinnerheaderfield ,or,iftheDatevalueisalso
verifywhetherthisrequirementappliesgenerallyorjustfor *
well *
wellforbackwardcompatibilitywithlegacyHPsystems ,suchas
whendisplayedtotheuser. *
wheneverpossible ,hasgrowninimportanceoverthepastyears.
wholeoriginalmessage.However ,forthepurposeofallowingthe
with *
withoutencryptiontomessagesintransitisnotconsidered *
withoutthe *
work-in-progress. *
workingdocumentsasInternet-Drafts.ThelistofcurrentInternet- *
wrapper. *

inactive/ietf-lamps-hp-requirements/review/draft-ietf-lamps-header-protection-requirements-01-pre20191028.txt pypi

1.1.RequirementsLanguage *
1.1.RequirementsLanguage..................4 *
1.2.Terms *
1.2.Terms..........................4 *
1.Ifaheaderfieldisbeingencryptedbecauseitissensitive ,its
1.Introduction *
1.Introduction........................3 *
1.ThemessagefortherecipientaddresseslistedinToorCcheader *
1.Theouterheaderfieldsmightbetamperedwith ,soareceiving
14CastleMews *
2.1.Privacy *
2.1.Privacy.........................4 *
2.2.Security *
2.2.Security........................5 *
2.3.Usability *
2.3.Usability........................5 *
2.4.Interoperability *
2.4.Interoperability....................5 *
2.ProblemStatement *
2.ProblemStatement......................4 *
2.Themessage *
2.TheouterheadersectionSHOULDbeminimalinordertoavoid *
3.1.Interactions *
3.1.Interactions......................5 *
3.2.ProtectionLevels *
3.2.ProtectionLevels....................6 *
3.The *
3.Themessagestoredinthe *
3.UseCases *
3.UseCases..........................5 *
4.1.1.SendingSide *
4.1.1.SendingSide....................7 *
4.1.2.ReceivingSide *
4.1.2.ReceivingSide...................8 *
4.1.GeneralRequirements *
4.1.GeneralRequirements..................7 *
4.2.1.Sendingside *
4.2.1.Sendingside....................8 *
4.2.2.Receivingside *
4.2.2.Receivingside...................9 *
4.2.AdditionalRequirementsforBackward-CompatibilityWith *
4.2.AdditionalRequirementsforBackward-CompatibilityWithLegacy *
4.3.1.SendingSide *
4.3.1.SendingSide....................9 *
4.3.2.ReceivingSide *
4.3.2.ReceivingSide...................9 *
4.3.AdditionalRequirementsforBackward-Compatibilitywith *
4.3.AdditionalRequirementsforBackward-CompatibilitywithLegacy *
4.Requirements *
4.Requirements........................7 *
4rev1 *
5.SecurityConsiderations *
5.SecurityConsiderations...................9 *
6.PrivacyConsiderations *
6.PrivacyConsiderations...................10 *
7.IANAConsiderations *
7.IANAConsiderations.....................10 *
8.Acknowledgments *
8.Acknowledgments.......................10 *
9.1.NormativeReferences *
9.1.NormativeReferences..................10 *
9.2.InformativeReferences *
9.2.InformativeReferences.................11 *
9.References *
9.References.........................10 *
A.1.1.Option1 *
A.1.2.1.Content-TypeParameter *
A.1.2.Option2 *
A.1.3.Option2.1 *
A.1.4.1.Option1 *
A.1.4.2.Option2 *
A.1.4.3.Option2.1ProgressiveHeaderDisclosure *
A.1.4.Examples *
A.1.4.Examples......................14 *
A.1.OptionstoAchieveHeaderProtection *
A.1.OptionstoAchieveHeaderProtection..........12 *
A.2.1.CandidateHeaderFieldsforHeaderProtection *
A.2.1.CandidateHeaderFieldsforHeaderProtection....20 *
A.2.SendingSideConsiderations *
A.2.SendingSideConsiderations...............20 *
A.3.1.WhichHeaderFieldstoDisplaytoUser *
A.3.1.WhichHeaderFieldstoDisplaytoUser.......22 *
A.3.2.MailUserAgentAlgorithmfordecidingwhichversion *
A.3.2.MailUserAgentAlgorithmfordecidingwhichversionofaheader *
A.3.ReceivingSideConsiderations *
A.3.ReceivingSideConsiderations..............21 *
Abstract *
AlexeyMelnikov *
AppendixA.1.2.1 *
AppendixA.ImplementationConsiderations *
AppendixA.ImplementationConsiderations...........12 *
AppendixB.DocumentChangelog *
AppendixB.DocumentChangelog.................22 *
AppendixC.OpenIssues *
AppendixC.OpenIssues....................23 *
Arangeofprotocolsfortheprotectionofelectronicmail *
Astandardforend-to-endprotectionoftheemailheadersection *
AuthorizingUseofDomainsinEmail ,Version1
Authors *
B1 *
BR1 *
BS1 *
BS2 *
BS3 *
BernieHoeneisen *
Bodies *
Butnotethathavingkeyheaderfieldsduplicatedintheouter *
CH-8046Zuerich *
CertainimplementationsMAYdecidetosend *
ClientsUnawareofHeaderProtection *
Content-Transfer-Encoding *
Content-Type *
Content-Typeparameter *
Copyright *
CopyrightNotice *
DOI10.17487 *
Date *
DavidWilsoncameupwiththeideaofdefininganewContent-Type *
Disclosure *
Email *
EmailHeaders *
Essentialpartsof havebeen
Examplesinsubsequentsectionsassumethatanemailclientistrying *
Expires *
Extensions *
FYI36 ,RFC4949,DOI10.17487
Fora *
Forbackwardcompatibilityoflegacyclients-unawareofanyHP- *
From *
G1 *
G2 *
G3 *
G4 *
GR1 *
GR2 *
GR3 *
GS1 *
GS2 *
GS3 *
GS4 *
Group.TheexistingS *
HFs. *
Hampton ,MiddlesexTW122NP
HeaderProtectionSystems *
Inordertoprotectouter ,non
Instructionsin describinghowtoprotecttheEmailmessage
Intendedstatus *
Internet-DraftHeaderProtectionrequirementsOctober2019 *
Internet-DraftIsodeLtd *
Internet-Draftsaredraftdocumentsvalidforamaximumofsixmonths *
Internet-DraftsareworkingdocumentsoftheInternetEngineering *
Inthefollowingalistofthegenericusecasesthatneedtobe *
Inthefollowingasetofchallengestobeaddressed *
Inthiscase ,the
IsodeLtd *
LS1 *
LS2 *
LSR1 *
LSS1 *
LSS2 *
LegacyClientsUnawareofHeaderProtection.......8 *
LegacyHeaderProtectionSystems *
Luck ,C.,
Luck.ForfurtherAcknowledgments ,pleaserefertoAcknowledgments
MIME andEmail
MIME-Version *
MIMEentityhasaContent-Typeofmessage *
MIMEheaderfields *
MMHS-Primary-Precedence *
Marques ,H.,
Melnikov *
Message-ID *
MessageAuthentication ,Reporting,andConformance
MessageSpecification *
Messagescontainingacryptographicsignature ,butwhichno
Messagescontainingacryptographicsignaturewhicharealso *
MessagescontainingatleastonerecipientaddressintheBccheader *
Messagesthatencryptionisappliedtowhichdonotcontaina *
Moreinformationonprogressiveheaderdisclosurecanbefoundin *
MultipurposeInternetMailExtensions *
NetworkWorkingGroupA.Melnikov *
Nomechanismforheaderprotection *
Note *
Notethatrecommendationslistedabovetypicallyonlyapplytonon *
Notethattheaboverecommendationscanalsonegativelyaffectanti- *
October2018. *
October28 ,2019
OneofthegoalsofthisdocumentistospecifyUIfordisplaying *
Phone *
PrivacyandsecurityissueswithemailheaderprotectioninS *
ProblemStatementandRequirementsforHeaderProtection *
Protection.TheIETFLAMPSWGmaychoosefromtheseoptionsinorder *
Protocols *
ProvisionsRelatingtoIETFDocuments *
RFC6376 ,DOI10.17487
RegardingtheBccheaderfieldthereshouldbenodifferencebetween *
RequirementLevels *
SHOULDNOTbeincludedintheouterheader *
SHOULDeitherbeidenticaltotheinner *
Section3.1 *
Section3.2 *
Sectionsforsignaturesandencryption *
SendingandreceivingsideSHOULDimplement *
Severalvaryingimplementationsofend-to-endprotectionsforemail *
SomeLAMPSWGparticipantsexpressedtheopinionthatwhatever *
StatusofThisMemo *
Subject *
Switzerland *
TableofContents *
TaskForce *
Thayer ,
TheLAMPSchartercontainsthefollowingWorkItem *
TheMemoryHoleapproachworksbycopyingthenormalmessageheader *
Theauthorswouldliketothankthefollowingpeoplewhohave *
ThecurrentpEpproposalisforPGP *
Thedocumentdoesnotdefineanewprotocol ,andthusdoesnotcreate
ThefollowingarecurrentoptionsforaddressingEmailHeader *
Thefollowingexampledemonstrateshowheadersectionandpayloadof *
Thefollowingintermediateusecasesmayneedtobeconsideredas *
Thefollowingisalistofrequirementsthatneedtobeaddressed *
Thefollowingprotectionlevelsneedtobeconsidered *
Thefollowingtermsaredefinedforthescopeofthisdocument *
Thekeywords *
ThemaindifferencecomparedtoOption2isanadditionalmultipart *
ThemaininteractioncaseforHeaderProtection *
TheneedformeansofDataMinimization ,whichincludesdata
ThepEpmessageformatisequivalenttotheS *
ThisAppendixAcontainsadditionalinformationandconsiderations *
ThisInternet-Draftissubmittedinfullconformancewiththe *
ThisInternet-DraftwillexpireonApril30 ,2020.
ThisdocumentdefinesanewContent-Typeheaderfieldparameter *
Thisdocumentdescribestheproblemstatement *
Thisdocumentdescribestheproblemstatement ,genericusecases,and
ThisdocumentissubjecttoBCP78andtheIETFTrust *
ThisdocumentrequestsnoactionfromIANA. *
ThisdocumenttalksaboutUIconsiderations ,includingsecurity
ThisisamultipartmessageinMIMEformat. *
ThisisanimportantmessagethatIdon *
ThisoptionissimilartoOption2 *
Thissectionoutlineshowthenew *
To *
UK *
UcomStandardsTrackSolutionsGmbH *
Updatethespecificationforthecryptographicprotectionofemail *
WhenanS *
WhendisplayingS *
WhengeneratingS *
Wilson ,KellyBristol,RobertWilliams,SteveKille,andWeiChuang.
Withoutmessageheaderprotectionthecorrespondingsignedmessage *
Wrappingwithmessage *
X-Mailer *
addressedformessageswithHeaderProtection *
alsoapplicabletoPGP *
and *
andReceivingsidesSHOULDimplement *
andadjustedtotheaboveS *
andaimtominimizetheimplementationefforttoincludesupport *
andhowheadersectionwrappingworks *
andistrusted. *
andmaybeupdated ,replaced,orobsoletedbyotherdocumentsatany
andselectivelymodifiescommunicateddatatomasqueradeasoneor *
andthenprependingthemwith *
andwithenclosedsignatureandnecessarypublickeyssothatreplies *
anynewsecurityconcernsnotalreadycoveredbyS *
applyindependentlyofwhetherS *
aprotectbodypartmightlooklike.Forexample ,thiswillbethe
arefurtherexplainedinSection3.2. *
aretobetreated. *
asforillustrativepurpose.Specificexamplescanbefoundin *
basedMessageAuthentication ,Reporting,andConformance
beforepublication. *
being *
bodypart ,extractheaderfieldsfromitandpropagatethemtothe
by *
canbeimmediatelyupgradedtoencryptedmessages. *
carefully ,astheydescribeyourrightsandrestrictionswithrespect
challengeandsomebestpracticesarecollected.Inanycase ,the
changesintheexistingcodebase.InparticularalsoMIME *
cleartextwithoutsignatureorencryption ,ortransferthemencrypted
clientSHOULDignorethem ,unlesstheyareprotectedinsome
clientsthatcan *
conflictinginformationbetweentheprotectedandunprotected *
conflictwithanynewsolutionforHPatallorwhether *
considerations ,whenprocessingmessagesprotectingHeaderFields.
containthetruevalue *
copied ,butalsothecontent.
correspondingoutervaluemustbeignored *
cryptographically-protectedelectronicmailprotectonlythebody *
cryptographicsignature. *
decidehowtopresentthis *
degree *
dependingonthecircumstancesandcustomerrequirements.Sending *
derived. *
describedintheSimplifiedBSDLicense. *
designatedaslegacyHP *
destinationheaderfieldismandatoryasper .
differ ,theycansimplybereplacedwiththeirprotectedversions
disclosureofconfidentialinformation.Itisrecommendedthat *
document *
documentaretobeinterpretedasdescribedin .
documentauthors.Allrightsreserved. *
doesnotsupportanyHP *
donotsupportS *
draft-ietf-lamps-header-protection-requirements-01 *
easilyimplementable.Unlessneededformaximizingprotectionand *
electronicmail.Mostcurrentimplementationsof *
emailheaderssectionorselectedheaderfields *
emails. *
encapsulatedandforwardedemails. *
encapsulatedemailsusingnewHPmechanism. *
encrypted. *
encryptedpayloadoftheapplication *
encryption *
encryptionapplied. *
encryptionisappliedto. *
encryptiontoprotectheaderfields *
ensuringheaderprotection ,inthatthewholemessageisprotected
exist ,whichallowtoassesstheauthenticityandintegrityofthe
existsforS *
field ,whichdependsontheimplementation
fieldmayappearinuptothreedifferentvariants *
fieldparametercouldbedefined *
fields *
fields ,whichmustnotincludetheBccheaderfieldneitherfor
fieldsintotheMIMEheadersectionofthetoplevelprotectedbody *
fieldsshouldbeomittedandreplacedwith *
fieldtodisplay *
finalsolutionistobedeterminedbytheIETFLAMPSWG. *
firstbodypartofamultipart *
for *
forexistingsolutions. *
foritsinnermostmessagestructure.Securitycomesjustnextafter *
formofactivewiretappingattackinwhichtheattackerintercepts *
forwarded =no
forwardedemails ,legacyencapsulatedemails,and
frequentlyusedbyIMAPclientsinordertoavoidparsingmessage *
fullysupportsHP *
global *
havebeenidentifiedforsometime.However ,thedesiretofixthese
header. *
headerfieldismandatoryaccordingto ,astubvalue
headerfieldisonlypresentintheouterheader ,itMAYbe
headerfieldparametertodistinguishforwardedmessagesfrominner *
headerfieldprotectionconstructs. *
headerfields.Andinthecasethatthe *
headerfields.Thiswouldmeanthatallheaderfieldsaresigned. *
headerisconvenientformanymessagestores *
headers-bothforsignaturesandencryption-toimprovethe *
headersection ,bywrappingthemessageinsideamessage
headersectionandarenotcapableofprovidingprivacyforthe *
headersectionsexist ,thoughthetotalnumberofsuch
i.e.withallrecipientaddresses. *
identicalto1. *
ignored *
implementationdocument. *
implementationsappearstoberatherlow. *
implementationsituationwithrespecttoprivacy ,security,
includeSimplifiedBSDLicensetextasdescribedinSection4.eof *
includedintheouterheader *
includesMIMEstructure ,Content
independentlyofwhetherS *
indicatorthatitisnottrustworthy *
informationcontainedtherein. *
insensitiveandcanbeeither *
insertionofpublickeys ,therootentityoftheprotectedmessageis
instead ,bywrappingitandprovidingcryptographicservicestothe
isitselfcoveredbytheprotectionmechanisms *
issuesaspreviouslydiscussed. *
issueshasonlyrecentlybeenexpressedintheIETFLAMPSWorking *
it. *
levelperspective ,specificallyDomainKeysIdentifiedMail
levelprotectbodypart *
librarieswidelyusedshallnotneedtobechangedtocomplywith *
maintained. *
makesusetheContent-Typeparameter *
materialortocitethemotherthanas *
meansthatthemessagenestedinside *
mechanismwillbechosen ,itshouldnotbelimitedtoS
mergedintothisdocument.SpecialthankstoitsauthorClaudio *
message *
mightlooklikethis. *
mixedContent-Typecontainingtheoriginalmessage *
moreoftheentitiesinvolvedinacommunicationassociation. *
normalmessageheaderfieldsintotheMIMEheadersectionofthetop *
notsupportanyHP *
oAddmoretextonMemoryHole *
oCorrectterminologyforHeader *
oDataMinimization ,whichincludesdatasparenessandhidingall
oDecideinwhichformlegacyHPrequirementsshouldremaininthis *
oEnhanceIntroductionandProblemStatementsections *
oHeaderField *
oHeaderProtection *
oHeaderSection *
oImprovedefinitionsinSection3.2 *
oInteroperabilitywith implementations
oMITMattacks *
oMan-in-the-middle *
oRephraseAppendixA.1.2 *
oReplace *
oResolvequestionregardingBccinAppendixA.2.1 *
oRewriteAppendixA.2.1 *
oShouldrequirementG3remain *
oUserinteraction *
oWriteAppendixA.3.2 *
odraft-ietf-lamps-header-protection-requirements-00 *
odraft-ietf-lamps-header-protection-requirements-01 *
ofaheaderfieldtodisplay............22 *
ofattacksonemail ,donotofferfullend
ofthemessage ,whichleavessignificantroomforattacksagainst
onlytheinnerheaderfieldvalueMUSTbedisplayed *
orderived. *
otherway *
otherwise-protectedmessages. *
pEpforemail definesafixedMIMEstructure
pEphasalsoimplementedtheabove *
parameters ,suchas
parametersetto *
part.SincetheMIMEbodypartheadersectionisitselfcoveredby *
particular ,Subject
particular ,Keywords,In
particulardowngradeattacks ,aremitigatedtothegreatestextent
particulardowngradeattacks ,canbedetected.
possible ,hasgrowninimportanceoverthepastseveralyears.
possible. *
prependedby *
privacy ,existingimplementationsshallnotrequiresubstantial
privacyinpEp ,forwhichreasontheapplicationofsignatures
protectionsofthemessagebody. *
protecttheinnerheadersection. *
providedhelpfulcommentsandsuggestionsforthisdocument *
provideheaderprotection.ThisentitySHOULDbepresentedasthe *
provisionsofBCP78andBCP79. *
publicationofthisdocument.Pleasereviewthesedocuments *
purposeful.pEpforemail ,eitherexpectstotransfermessagesin
receivingsideneedscertainguidelinesonhowtoprocessreceived *
recipients *
regardingheaderprotection. *
regardingtheimplementation.Althoughnot *
requirements ,thisisusefultobetterunderstandthem.Partsofthe
requirementsofheaderprotection. *
returnedinIMAPENVELOPEFETCHdataitem ,whichis
rfc822container arethusupdatedtoread
sectionof .
sensitive ,toMonday9amofthesameweek
separatelywithaBccheaderfieldcontainingonlytheaddressof *
sidefullysupportsHP *
signaturecalculationnorforencryption. *
someotherway ,forexamplewithaDKIMsignaturethatvalidates
spamprocessing. *
sparenessandhidingalltechnicallyconcealableinformationwhenever *
specificimplementations. *
suchas *
suchmessageswhichislessconfusing *
supportslegacyHPonly *
technicallyconcealableinformationwheneverpossible *
technologyisusedtoachieveHP. *
textinthisAppendixAwilllikelybemovedtotheupcoming *
thatall *
theTrustLegalProvisionsandareprovidedwithoutwarrantyas *
thefollowingintermediateinteractionsneedtobeconsideredas *
theinnerandtheouterheadersection. *
thenewmechanismforHP. *
theouterheadersectiononlycontains *
theprotectionmechanisms *
thepublickey *
therecipientitissentto *
thisdocument. *
thusmoresecure. *
thusnestedoncemoreintoanadditionalmultipart *
time.ItisinappropriatetouseInternet-Draftsasreference *
tobeincludedintheouterheadersection. *
tobeusedfordisplay *
top-levelmessage ,takingintoaccountheadersectionmerging
toplevel.Thisshouldalsoworkfortriple-wrappedmessages. *
toprotect *
totheseheaderfields. *
totheseheaderfields.Itisuptothereceivingclientto *
tothisdocument.CodeComponentsextractedfromthisdocumentmust *
toupdate .
truevalueMUSTNOTbeincludedintheouterheader.Ifthe *
unprotected *
usabilityandinteroperabilityincryptographically-protected *
usecases *
usedtoapplyHPto. *
usuallycontainstheBccunchangedfromtheoriginalmessage ,
value ,orcontainaclearindicationthattheoutervalueisnot
valueasintheinnerheaderfield ,or,iftheDatevalueisalso
verifywhetherthisrequirementappliesgenerallyorjustfor *
well *
wellforbackwardcompatibilitywithlegacyHPsystems ,suchas
whendisplayedtotheuser. *
whichdoesnotincludeaBccheaderfield *
wholeoriginalmessage.However ,forthepurposeofallowingthe
withaBccheaderfieldcontaininganindicationsuchas *
withoutencryptiontomessagesintransitisnotconsidered *
withoutthe *
work-in-progress. *
workingdocumentsasInternet-Drafts.ThelistofcurrentInternet- *
wrapper. *

inactive/medup-requirements/archive/draft-symeonidis-medup-requirements-00.txt pypi

1.1.RequirementsLanguage *
1.1.RequirementsLanguage..................3 *
1.2.Terms *
1.2.Terms..........................3 *
1.Bothpeershavenopublickeyofeachother ,notrustpossible
1.Introduction *
1.Introduction........................3 *
10.Acknowledgments *
10.Acknowledgments.......................16 *
11.1.NormativeReferences *
11.1.NormativeReferences..................16 *
11.2.InformativeReferences *
11.2.InformativeReferences.................16 *
11.References *
11.References.........................16 *
2.1.Objectives *
2.1.Objectives.......................4 *
2.2.1.PrettyEasyPrivacy *
2.2.2.Autocrypt *
2.2.2.Autocrypt......................6 *
2.2.KnownImplementations *
2.2.KnownImplementations..................4 *
2.3.FocusAreas *
2.MotivationandBackground *
2.MotivationandBackground..................4 *
2.Onlyonepeerhasthepublickeyoftheotherpeer ,butnotrust
29 ,avenueJFKennedy
3.1.Entities *
3.1.Entities........................6 *
3.2.BasicFunctionalRequirements *
3.2.BasicFunctionalRequirements..............7 *
3.Onlyonepeerhasthepublickeyoftheotherpeerandtrusts *
3.SystemModel *
3.SystemModel........................6 *
3a *
4.1.Adversarialmodel *
4.1.Adversarialmodel....................7 *
4.2.1.SpoofingandEntityAuthentication *
4.2.1.SpoofingandEntityAuthentication.........8 *
4.2.2.InformationDisclosureandConfidentiality *
4.2.2.InformationDisclosureandConfidentiality.....8 *
4.2.3.TamperingWithDataandDataAuthentication *
4.2.3.TamperingWithDataandDataAuthentication.....8 *
4.2.4.RepudiationandAccountability *
4.2.SecurityThreatsandRequirements *
4.2.SecurityThreatsandRequirements............8 *
4.3.1.Identifiability-Anonymity *
4.3.1.Identifiability-Anonymity.............9 *
4.3.2.Linkability-Unlinkability *
4.3.2.Linkability-Unlinkability.............10 *
4.3.3.DetectabilityandObservability-Undetectability *
4.3.3.DetectabilityandObservability-Undetectability..10 *
4.3.PrivacyThreatsandRequirements *
4.3.PrivacyThreatsandRequirements............9 *
4.4.InformationDisclosure-Confidentiality *
4.4.InformationDisclosure-Confidentiality........10 *
4.5.Non-repudiationandDeniability *
4.5.Non-repudiationandDeniability.............10 *
4.Bothpeershavethepublickeyofeachother ,butnotrust
4.ThreatAnalyses *
4.ThreatAnalyses.......................7 *
5.1.1.SendMessage *
5.1.1.SendMessage....................11 *
5.1.2.ReceiveMessage *
5.1.2.ReceiveMessage...................11 *
5.1.MessagesExchange *
5.1.MessagesExchange....................11 *
5.2.TrustManagement *
5.2.TrustManagement....................12 *
5.3.KeyManagement *
5.3.KeyManagement.....................12 *
5.4.SynchronizationManagement *
5.4.SynchronizationManagement...............12 *
5.5.IdentityManagement *
5.5.IdentityManagement...................13 *
5.6.UserInterface *
5.6.UserInterface.....................13 *
5.Bothpeershaveexchangedpublickeys ,butonlyonepeertrusts
5.SpecificSecurityandPrivacyRequirements *
5.SpecificSecurityandPrivacyRequirements.........11 *
54-68 ,2002.
5b ,6
6.1.4 ,non
6.1.InteractionStates *
6.1.InteractionStates...................13 *
6.2.SubcasesforSendingMessages *
6.2.SubcasesforSendingMessages..............14 *
6.3.SubcasesforReceivingMessages *
6.3.SubcasesforReceivingMessages.............15 *
6.Bothpeershaveexchangedpublickeys ,andbothpeerstrustthe
6.Subcases *
6.Subcases..........................13 *
7.SecurityConsiderations *
7.SecurityConsiderations...................15 *
8.PrivacyConsiderations *
8.PrivacyConsiderations...................16 *
9.IANAConsiderations *
9.IANAConsiderations.....................16 *
Abstract *
Adevicegroupiscomprisedofdevicesbelongingtooneuser ,which
Adversariescanrepudiate ,ordeny,thestatusofthemessageto
Anadditionalsetofusecasesappliestoenterpriseenvironments *
Anadversaryaimstoeavesdropanddiscloseinformationaboutthe *
Anadversarycanalsomodifytheinformationstoredandexchanged *
Anadversaryisanyentitywholeveragesthreatsagainstthe *
AnotherknownapproachinthisareaisAutocrypt.ComparedtopEp *
AppendixA.DocumentChangelog *
AppendixA.DocumentChangelog.................18 *
AppendixB.OpenIssues *
AppendixB.OpenIssues....................18 *
Attackerscancombinetheseadversarialpropertiesinanumberof *
Authors *
BernieHoeneisen *
Birk ,V.,Marques,H.,andB.Hoeneisen,
CH-8046Zuerich *
Considerations *
ConsiderationsforInternetProtocols *
Copyright *
CopyrightNotice *
D.Zappala ,
DOI10.17487 *
DataMinimization ,End
Detectabilityoccurswhenanadversaryisabletosufficiently *
Email *
EncryptedMessagingProtocols *
Ermoshina ,K.,Musiani,F.,andH.Halpin,
Essentially ,inordertomakeanonymitypossible,therealwaysneeds
Expires *
FYI36 ,RFC4949,DOI10.17487
Francisco ,CA,USA,April14
Goldberg ,I.,andM.Smith,
IEEEProceedings-2015IEEESymposiumonSecurityand *
Identifiabilityisdefinedastheextenttowhichaspecificusercan *
Identificationistheprocessoflinkinginformationtoallowthe *
InMEDUPtheseissuesareaddressedbasedonOpportunisticSecurity *
Informationdisclosure-orlossofconfidentiality-aboutusers ,
Intendedstatus *
Internet-DraftPriv.Messaging *
Internet-DraftUniversityofLuxembourg *
Internet-Draftsaredraftdocumentsvalidforamaximumofsixmonths *
Internet-DraftsareworkingdocumentsoftheInternetEngineering *
Inthesimplifiedmodel ,onlyinteractionstates1,2,4and6are
IraklisSymeonidis *
July08 ,2019
KellyBristol ,KristaBennett,andNanaKarlstetter.
L-1855Luxembourg *
Linkabilityoccurswhenanadversarycansufficientlydistinguish *
Luxembourg *
March2019. *
Marques ,H.andB.Hoeneisen,
Messaging *
Morris ,J.,Hansen,M.,andR.Smith,
MostoftheTime *
NetworkWorkingGroupI.Symeonidis *
Non-repudiationcanbeachievedwiththeuseofcryptographicschemes *
Non-repudiationcanbeathreattoauser *
Note *
Pfitzmann ,A.andM.Hansen,
Phone *
Privacy ,SP2015,pages232
PrivacyandSecurityThreatAnalysisandRequirementsforPrivate *
PrivacybyDefault *
ProtocolConsiderations *
ProvisionsRelatingtoIETFDocuments *
RegistrationofTrustwordLists *
RelevantprivacyconsiderationsareoutlinedinSection4.3. *
RelevantsecurityconsiderationsareoutlinedinSection4.2. *
RequirementLevels *
Reset *
Section2.2.1above. *
Section5.4 *
Spoofingoccurswhenanadversarygainsimproperaccesstothesystem *
StatusofThisMemo *
Switzerland *
Symeonidis *
TOFU.Forabetterunderstanding ,youmayconsultthefigurein
TableofContents *
TaskForce *
Technologies ,SecondInternationalWorkshop,San
Thayer ,
Theauthorswouldliketothankthefollowingpeoplewhohave *
Thebasicmodelconsistsofdifferentinteractionstates *
Thefollowingtableshowsthedifferentinteractionstatespossible *
Thefollowingtermsaredefinedforthescopeofthisdocument *
Thekeywords *
Therefore ,nohonestpartyshouldacceptamessagethatwasmodified
Therefore ,confidentialityofmessagesexchangedwithinasystem
ThisInternet-Draftissubmittedinfullconformancewiththe *
ThisInternet-DraftwillexpireonJanuary9 ,2020.
ThisdocumentissubjecttoBCP78andtheIETFTrust *
ThisdocumentrequestsnoactionfromIANA. *
Thisdocumentscoversanalysisofthreatstoprivacyandsecurityand *
Thissectiondescribesasetofpossiblethreats.Notethatnotall *
Thissectionoutlinesthefunctionalrequirements.Wefollowthe *
Toachieveprivacyofexchangedmessagesinanopportunisticway *
UcomStandardsTrackSolutionsGmbH *
UniversityofLuxembourg *
abilitytocorrelatenetworktraffic ,whichiscrucialin
abnormaluserbehavior.Interactionstates1 ,2and4arepartof
aboutprivacybydataminimization *
aboutsendingorreceivinganemail.Anadversarycanbeanyonewho *
addition ,pEpprovidestechnicaldataprotectionincludingmetadata
adevicegroup ,devicesofthesameusermutuallygrant
adversarycanonlycompromisethecommunicationchannels *
adversarycantamperwiththemessagesofatargetedmessaging *
adversarymayalsoattempttosendorreceivemessagesonbehalfof *
adversarymayattempttoalteranemailoraninstantmessageby *
amessage.Anonymitycanbeachievedwiththeuseofpseudonymsand *
anIOIisdefinedasthat *
anMiTMattack ,ifsuchanattackdidnotsucceedduringthe
anactionperformed.Forinstance ,anadversarymayidentifythe
andcontrolseveralpartsofthenetwork ,grantingthemthe
anddigitalsignatures. *
andmaybeupdated ,replaced,orobsoletedbyotherdocumentsatany
andselectivelymodifiescommunicateddatatomasqueradeasoneor *
anonymouscommunicationschannels *
applicationslackPrivacysupportthattheaverageusercaneasily *
attacks.Forinstance ,anexternalglobalpassiveattackercan
authenticatedusingthecachedkeyorcredentialissecureagainst *
authenticatingthatassertion.Subsequentcommunicationthatis *
authentication. *
background.html *
beforepublication *
beguaranteedthroughtheuseofpseudonymsaswellascryptographic *
beidentifiedfromasetofusers ,whichistheidentifiabilityset.
beingaininglocalcontrolofanentitywhichcanaltermessages ,
betweenthecommunicationentitiesinthesystem.Forinstance ,an
betweentwopeers ,eachpossessingasinglekeypair.
blowersmayfindnon-repudiationusedagainstthembyadversaries ,
butalsoaprivacythreatthatacommunicatingsystemcanface.For *
canbeachievedthroughtheuseofcryptographicschemessuchasmix- *
canidentifyaspecificuserassociatedwithItemsofInterest *
canneitherconfirmnorcontradictthataspecificusersenta *
carefully ,astheydescribeyourrightsandrestrictionswithrespect
cases *
caseswherehumanlivesareatstake.Adversariesinthese *
changingthecontentofthem.Asaresult ,itcanbeanyonebutthe
clearerdistinctionbetweenMEDUPrequirements ,andthoseofa
collectinginformationtransmittedbetweentheintendedusers.The *
communicatewithdifferentend-users.Inordertomitigatespoofing *
communicatinguserisequallylikelytobeofanyotheruserinthe *
communicationlinkswithinthechannel.Thatgrantstheadversary *
communicationsystem ,whosegoalistogainimproperaccesstothe
communicationsystemtoprovetoothersthatawhistle-blowinguser *
complex.Fornow ,wewillfocusonasinglebilateralinteraction
compliancerequirementsorvirus *
contentofamessage.Theycanattempttoperformaman-in-the- *
conversationsareoccurring ,interactionstatesbecomeincreasingly
credentialassociatedwithanassertedidentity ,without
cryptographicprotocolssuchasoff-the-recordmessaging. *
cryptographicschemessuchasanonymousremailers *
deliveryandsynchronization. *
deniabilityisessentialfortheseusers ,toensurethatanadversary
depicted.States3and5mayresultfrome.g.keymistrustor *
derivesrequirementsfromthisthreatanalysis. *
describedintheSimplifiedBSDLicense. *
detectabilityoccursalongwithalossofanonymityfortheentities *
distinguishanIOI ,suchasmessagesexchangedwithinthesystem,
distinguishwhetheritexistsornot. *
document *
documentaretobeinterpretedasdescribedin .
documentauthors.Allrightsreserved. *
draft-symeonidis-medup-requirements-00 *
enableaccesstofundamentalHumanRights.While *
entities ,witheachcompromisedaccounttypicallyisusedto
entityorpreventingamessagefrombeingsent.Anexternal *
example ,asuccessfulMitMattackcanyieldmetadatathatcanbeused
exchangemessages ,typicallyreferredtoassendersandreceivers.
extractinformation ,whileanactiveattackercantamperwiththe
formofactivewiretappingattackinwhichtheattackerintercepts *
found. *
frequently.Toguaranteetheconfidentialityofmessagesandprevent *
fromrandomnoise .Observabilityoccurswhenthat
gainingaccesstothemessagingserverandremainundetectablewhile *
guaranteed ,whichalsoensuresunobservability.Undetectabilityfor
guaranteed ,suchaswiththeuseofMessageAuthenticationCode
homomorphicencryptionandsecretsharing. *
identifiedinthisprocess *
implementations. *
implementationsoftheseconceptsarealreadyavailable ,manycurrent
improvedinfuturerevisions.Amongotherthings ,thereneedstobe
includeSimplifiedBSDLicensetextasdescribedinSection4.eof *
inferenceofaparticularuser *
informationdisclosure ,securitymeasuresneedtobeguaranteedwith
inscope ,suchasseizingglobalcontrolofseveralentitiesand
instantmessaging .
intransit.Dataauthenticationofmessagesexchangedneedstobe *
involvedincommunication ,suchasusersofthesystem,message
isinvolvedincommunicating ,suchastheusersofthesystem,the
istypicallybasedonthelocalcontrolofoneentityorasetof *
linkwithinthenetwork.Theadversarialthreatcanalsobebroader *
materialortocitethemotherthanas *
message *
messagecontent ,metadataorotherinformationisnotonlyasecurity
messagecontent.Reasonsforthismayincludetheneedtoconformto *
messagecontentandusers *
messageoperators ,andthenetworknodes.Tomitigaterepudiation
messagesthemselves ,suchasadding,removing,orevenmodifying
messagingserviceaccount.Theentityauthenticationmechanisms *
messagingsystems ,incontrasttosecurity.Asdiscussedinsection
middleattack *
monitormultiplechannelsofasystem ,whileaninternallocalactive
moreoftheentitiesinvolvedinacommunicationassociation. *
mustbeguaranteed.Non-repudiationofactioncanincludeproofof *
navigate. *
navigate.Thisdocumentcoversanalysisofthreatstoprivacyand *
netsandobfuscationmechanismssuchastheinsertionofdummy *
networknode ,orthirdparties.Thethreatposedbyanadversarycan
oAddanotherdeviceofthesameusertoexistingdevicegroup *
oAddmoretextonGroupMessagingrequirements *
oAddreferencestousedmaterials *
oAllinvolvedpartiessharethesameidentitysystem *
oAnopenstandardforsecuremessagingrequirements *
oCommonpitfalls *
oConversationsecurity *
oDecideonwhetherornot *
oFormadevicegroupoftwo *
oFuturedirectionsonrequirementsandtechnologies *
oGetcontentfromAutocrypt *
oGroupmessaging *
oIdentitymanagement *
oIfpeer *
oInternal-external *
oKeymanagement *
oKeypairisdeclaredinvalidandotherpeersareinformed *
oLeavedevicegroup *
oLocal-global *
oMan-in-the-middle *
oMessage *
oMessagingoperatorsandnetworknodes *
oMisleadingproductsonthewild *
oMulti-devicesupport *
oNewKeypairisautomaticallygeneratedatstartupifnoneare *
oOncereceived ,PublicKeyisstoredlocally
oPassive-active *
oPrivateKeysaresynchronizedamongauser *
oPublicKeyismarkedinvalidafterreceivingakeyresetmessage *
oPublicKeyissenttopeerviamessageattachment *
oPublicKeysofpeersaresynchronizedamongauser *
oReceiveencrypted ,butunsignedmessagefromanotherpeer
oReceiveencryptedandsignedmessagefromanotherpeer *
oReceivesigned ,butunencryptedmessagefromanotherpeer
oReceiveunencryptedandunsignedmessagefromanotherpeer *
oRemoveotherdevicefromdevicegroup *
oSendencryptedandsignedmessagetoanotherpeer *
oSendunencryptedandunsignedmessagetoanotherpeer *
oThirdparties *
oTransportprivacy *
oTrustOnFirstUse *
oTrustestablishment *
oTrustmanagement *
oTrustofapublickeyissynchronizedamongdifferentdevicesof *
oTrustratingofapeerisupdated *
oTrustwords *
oUnifiedevaluationframework *
oUsers ,senderandreceiver
odraft-symeonidis-medup-requirements-00 *
ofusersmustbeguaranteed.Anonymityisdefinedfromtheattackers *
one-cell-enough-break-tors-anonymity *
only.Insomeinstances ,theenterprisemayrequireaccessto
operators ,networknodes,oreventhirdparties.
orbiometricdatalikefingerprints. *
ordertoinferlinkabilityandpossiblyidentificationofusers *
origin ,submission,delivery,andreceiptbetweentheintendedusers.
other .Forinstance,anadversarymaybeabletorelate
other *
pEpisintendedtobeusedinpre-existingmessagingsolutionsand *
pEpisintendedtosolvethreeproblems *
part *
particularlyincountrieswithstrictcensorshippoliciesandin *
particularmessage.Deniabilitycanbeguaranteedthroughtheuseof *
partofasystem ,whileaglobaladversarycanseizecontrolof
peersareshowncombinedTrustwordsofbothpublickeysinvolved *
performingMan-in-the-Middle *
performingtimingattacks. *
perspectiveasthe *
placethatwillverifythatauseristhelegitimateownerofa *
pointofacommunicationchannelsuchasanentityoracommunication *
positionthemselvesbetweentwocommunicatingparties ,suchas
pp.244-254 ,2016.
progress *
protection. *
protocol ,TOFUcallsforacceptingandstoringapublickeyor
providePrivacybyDefault ,ataminimum,formessagecontent.In
providedfeedbackorsignificantcontributionstothedevelopmentof *
provideinaccurateinformationaboutanactionperformed ,suchas
provider .
providersandnetworknodesthatareresponsibleformessage *
provisionsofBCP78andBCP79. *
pseudonymity ,andidentitymanagement
pseudonymsbelongtooneuser *
pseudonymsbyanalyzingexchangedmessagesanddeducethatthe *
publicationofthisdocument.Pleasereviewthesedocuments *
regardingtheprioritizationofsupportforlegacyPGP *
repudiationcarriesapotentialthreatvectorinitselfwhenitis *
requirementsextractedfromtheliteratureonprivateemailsand *
revocationoftrust *
schemessuchasanonymouscredentials. *
scopeofMEDUP *
securityandderivesrequirementsfromthisthreatanalysis. *
senderofamessagebyexaminingtheheadersofamessageexchanged *
set .Thus,anadversarycannotidentifywhoisthesenderof
severalentitiesinasystem.Aglobaladversarycanalsomonitor *
sharethesamekeypairsinordertosynchronizedataamongthem.In *
shouldbeguaranteedwiththeuseofencryptionschemes *
situationsmayseektouseshredsofevidencecollectedwithina *
sok-secure-messaging >.
specificimplementation. *
subjectwithinasetofsubjects ,theanonymityset
suchasdigitalsignaturesandaudittrailssuchastimestamps. *
system. *
thatpublickey *
thatuser.Thethreatposedbyanadversary *
theTrustLegalProvisionsandareprovidedwithoutwarrantyas *
theabilitytocorrelateandcontroltrafficinordertoexecute *
them. *
themselves ,eavesdroppingandtamperingwithmessagingsuchas
theotherpeer *
thesameuser *
theuseofcryptographicschemessuchassymmetric ,asymmetricor
thisdocument *
threatposedbyanadversarycanbefromlocalgainingcontrolofone *
threats ,accountability,andnon
threats ,itisessentialtohaveentityauthenticationmechanismsin
threatscanbeaddressed ,duetoconflictingrequirements.
time.ItisinappropriatetouseInternet-Draftsasreference *
timingattacks ,evenintheend
to65535 *
tobeasetofpossibleuserssuchthatforanadversarythe *
todeterminewithwhomaspecificusercommunicateswith ,andhow
toeasethecomparison. *
tothisdocument.CodeComponentsextractedfromthisdocumentmust *
trafficwithinasystem. *
trust *
typicallyrelyontheinformationorphysicaltraitsthatonlythe *
unlinkability ,undetectability,unobservability,
uponsuccessfullyimpersonatingtheprofileofavaliduser.The *
usedagainstauserincertaininstances.Forexample ,whistle
user *
users *
usersofthesystem.Forinstance ,anadversarymayattemptto
userswhoarecommunicating ,suchasthemessageoperators,the
usuallyresultinginaMitMattackonanencryptedchannel. *
validusershouldknow *
vulnerableinitialcommunication. *
wastheoriginatorofaspecificmessage.Therefore ,plausible
ways ,increasingtheeffectiveness
whichincludeitemssuchastheIDofasubject ,asentmessage,or
withinagivensystemthattwoormoreIOIssuchassubjects *
withinasystem.Therefore ,undetectabilityofIOIsshouldbe
withinasystem.Tomitigateidentifiabilitythreats ,theanonymity
withinthatsamesystem.Anadversarycanexploitthesestatesin *
withinthesystem ,suchasextractinginformationfromaspecific
workingdocumentsasInternet-Drafts.ThelistofcurrentInternet- *